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ABSTRACT 

This  study  investigates  current  thinking  on  the  systems 
approach  to  management  and  its  applicability  to  the  project 
manager  as  an  individual  in  the  Naval  laboratory,  specifi- 
cally the  Naval  Electronics  Laboratory  Center  (NELC)  in  San 
Diego,  California.   It  looks  at  the  NELC  organization, 
management  roles,  conflicts,  interfaces,  problems  and  some 
procedures  which  are  used  by  project  managers  in  planning 
and  controlling. 

The  authors  conclude  that  laboratory  project  managers 
can  be  more  effective  if  they  have  some  management  orienta- 
tion or  philosophy,  and  that  the  management  philosophy  that 
best  fits  the  laboratory  environment  is  the  systems  approach 
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I.   INTRODUCTION 

A.   THE  PROBLEM 

The  Naval  Electronics  Laboratory  Center  in  San  Diego, 
California  is  one  of  seventeen  Naval  laboratories  which 
conducts  research  and  development  projects.   The  projects 
within  the  laboratory  are  normally  headed  by  a  designated 
project  manager  who  is  responsible  to  both  the  project 
sponsor  and  the  laboratory.   The  majority  of  these  project 
managers  have  technical  backgrounds  and  are  technically 
oriented;  they  are  engineers  who  have  been  thrust  into  a 
difficult  job  which  requires  both  engineering  and  managerial 
talent.   By  background,  experience  and  education  they  are 
skilled  in  the  required  technical  areas  but  have  generally 
not  had  to  give  much  thought  to  managerial  problems. 

The  problem  faced  by  the  laboratory  project  manager  is 
first  to  recognize  the  importance  of  managerial  skills,  and 
then  do  something  about  acquiring  those  skills  so  he  can 
perform  more  effectively.   Whether  these  engineers  should 
receive  managerial  training  before  they  move  from  the  lab- 
oratory bench  to  the  position  of  project  manager  is  no 
longer  a  question.   Today,  research  and  its  applications 
are  becoming  more  management  intensive  and  all  phases  of 
the  acquisition  process  are  receiving  detailed  attention 
at  every  level  in  the  Navy.   An  increased  Insistence  on 
accountability  and  performance  point  to  a  need  for  a  higher 
degree  of  management  orientation. 
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In  this  paper,  the  management  problems  which  the  pro- 
ject manager  must  confront  in  the  Naval  laboratory  environ- 
ment and  a  view  of  management  which  can  be  used  to  cope  with 
these  problems  will  be  presented. 

B.   THE  HYPOTHESIS 

Naval  laboratory  project  managers  in  general  are  tech- 
nically oriented,  have  technical  backgrounds  but  are  some- 
times lacking  in  the  management  orientation  which  is 
important  to  the  project  manager.   The  transition  from 
engineer  to  project  manager  requires  some  change  of  motiva- 
tion, new  skills  must  be  learned  and  one's  scope  and  view 
must  be  expanded.   Senior  managers  often  give  little  atten- 
tion to  these  needs,  for  they  made  the  transition  from 
engineer  or  scientist  to  manager  long  ago  and  have  outgrown 
the  difficulties  they  felt  at  the  time.   The  management 
training  offered  is  often  poorly  related  to  the  problems 
involved  in  project  management  and  the  new  project  manager 
is  left  to  find  his  own  way,  sometimes  at  the  project's  and 
organization's  expense. 

Therefore,  it  is  the  hypothesis  of  this  paper  that  the 
laboratory  project  manager  needs  some  management  orientation 
to  successfully  deal  with  the  management  problems  inherent 
In  a  project.   This  does  not  mean  to  imply  that  his  techni- 
cal orientation  is  any  less  important  or  that  technical 
skills  should  suffer  because  he  develops  a  management  phi- 
losophy.  The  authors  believe  that  for  a  project  manager  to 
effectively  manage  a  project,  he  needs  a  management  orientation 


to  compliment  his  technical  ability.   In  addition,  the 
management  orientation  or  philosophy  which  he  should  use 
is  the  systems  approach  to  management.   He  cannot  walk 
around  in  a  world  of  his  own  but  must  realize  that  "every- 
thing depends  on  everything  else." 

C.   THE  APPROACH 

The  purpose  of  the  investigations  and  research  conducted 
was  to  examine  the  techniques  of  control  and  management  used 
by  project  managers  in  a  Naval  laboratory  and  determine  the 
organizational  structure  and  procedures  which  form  the 
basis  of  the  laboratory's  working  relationships.   In  addi- 
tion, various  articles  and  books  were  researched  to  confirm 
the  authors'  thoughts  as  to  what  constitutes  the  total  sys- 

i 

terns  approach  to  management. 

The  approach  to  this  study  consisted  of  three  basic 
phases.   The  first  phase  involved  three  visits  to  NELC  at 
San  Diego  to  conduct  interviews  with  project  managers,  re- 
search engineers,  operations  analysts,  contracting  special- 
ists, contracting  officers  and  a  project  manager  outside 

2 

NELC.    This  phase  also  included  one  visit  to  the  Naval 

Weapons  Center,  China  Lake,  California  in  an  effort  to 
discover  problems  and  techniques  common  to  project  managers 


Cleland,  D.  I.  and  King,  W.  R.  ,  Management:   A  Systems 
Approach,  p.  1^12,  McGraw-Hill,  1972. 

2 
An  interview  was  conducted  with  Mr.  John  Heising,  Viking 

Program  Manager  for  Teledyne  Ryan  in  San  Diego,  to  obtain  a 
feeling  for  some  procedures  and  techniques  used  by  a  non- 
laboratory  project  manager. 
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in  both  NELC  and  NWC  through  interviews  with  personnel  in 
positions  similar  to  those  interviewed  earlier.   Over  a  six 
month  period,  a  total  of  nineteen  interviews  were  conducted 
and  the  laboratory/project  organization  and  procedures  were 
reviewed  in  depth. 

The  second  phase  of  the  approach  involved  primarily 
library  research  into  the  theory  of  the  systems  approach  to 
management.   The  current  thought  and  direction  of  the  sys- 
tems theory  was  reviewed  along  with  its  application  in 
various  organizations .   The  timing  of  this  phase  overlapped 
the  other  two  phases  and  a  portion  of  it  was  accomplished 
between  visits  to  the  laboratories. 

The  third  phase  was  the  main  thrust  of  this  paper  and 
consisted  of  an  application  of  the  systems  approach  to  the 
laboratory  project  manager's  environment  through  an  analysis 
of  the  data  obtained. 
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II.   THE  SYSTEMS  APPROACH  TO  MANAGEMENT 

A.  INTRODUCTION 

This  chapter  will  discuss  the  concept  of  a  systems 
approach  to  management.   The  application  of  the  systems  ap- 
proach to  project  management  in  a  Naval  laboratory  will  be 
discussed  in  Chapter  IV. 

In  current  writings  on  the  subject  of  total  systems  ap- 
proach ,  there  is  no  obvious  agreement  as  to  the  meaning  of 
"total  systems."   Some  authors  contend  that  while  a  total 
systems  approach  is  theoretically  possible,  practically 
speaking  it  is  not  feasible.    Other  authors  believe  that 
the  key  utility  of  the  systems  viewpoint  is  not  in  its  aca- 
demic  value,  but  rather  its  applicability  to  the  real  world. 
There  are  some  indications  that  the  term  "total  systems  ap- 
proach" is  used  rather  loosely  and  with  little  consistency 
as  to  its  meaning.   Therefore,  it  seems  appropriate  at  this 
time  to  provide  an  understanding  of  the  term  which  will  fit 
with  the  concept  and  application  as  intended  for  this  paper. 

B.  THEORETICAL  ASPECTS 

Before  "systems  approach"  is  discussed,  an  understanding 
of  the  various  meanings  of  the  word  system  should  be  presented 


^Brooker,  W.  M.  A. ,  "The  Total  Systems  Myth,"  in  Emerging 
Concepts  in  Management,  ed .  by  Wortman,  M.  S.,  Jr.  and 
Luthans,  P.,  pp.  362-370,  Macmillan,  1969. 

Cleland,  op.    cit.>    p.  I'l6. 
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The  Dictionary  defines  system  as: 

. . .1.   a  set  or  arrangement  of  things  so  related  or 
connected  as  to  form  a  unitary  or  organic  whole: 
as  ,  a  solar  system,  irrigation  system,  supply  system. 
2.   the  world  or  universe.   3-  the  body  considered 
as  a  functioning  organism:   as,  my  system  needs  ton- 
ing up.   4.  a  set  of  facts,  principles,  rules,  etc. 
classified  or  arranged  in  a  regular,  orderly  form  so 
as  to  show  a  logical  plan  linking  the  various  parts. 
5.   a  method  or  plan  of  classification.   6.   a  regu- 
lar, orderly  way  of  doing  something;  order;  method; 
regularity.   7.   a  number  of  bodily  organs  acting 
together  to  perform  one  of  the  main  bodily  functions: 
as,  the  circulatory  system,  digestive  system.   8. 
an  arrangement  of  rocks  showing  evidence,  as  through 
fossils,  of  having  been  formed  during  a  given  geolog- 
ical period:   as,  the  Devonian  system.   9.   a  group 
of  transportation  lines  under  a  common  owner.   10.  in 
chemistry,  a  group  of  substances  in  or  approaching 
equilibrium:   a  system  with  two  components  is  called 
binary,  one  with  three,  ternary,  etc.... 5 

There  appears  to  be  as  many  definitions  of  system  as  there 

are  texts  written  on  the  systems  approach.   As  one  text  on 

systems  theory  and  management  states: 

The  concept  of  a  "system"  is  getting  a  great  deal  of 
attention  in  both  industrial  and  academic  circles. 
Unfortunately,  the  word  has  many  meanings;  for  pur- 
poses of  this  discussion,  a  system  is  simply  an  as- 
semblage or  combination  of  things  or  parts  forming 
a  complex  whole.   One  of  its  most  important  charac- 
teristics  is  that  it  is  composed  of  a  hierarchy  of 
subsystems . ° 

Some  of  the  earlier  and  more  influential  (judging  from  the 

number  of  times  they  are  referenced  in  readings  on  system 

theory)  proponents  of  the  systems  approach,  Johnson,  Kast 


^Webster's  Mew  World  Dictionary  of  the  American  Language, 
College  Edition,  ed .  by  Guralnik,  D.  B.  and  Friend,  J.  H., 
pp.  1480-81,  World  Publishing,  196'l  . 

c. 

Martin,  E.  W. ,  Jr.,  "The  Systems  Concept,"  in  Systems , 
Organizations,  Analysis,  Management:   A  Book  of  Readings, 
ed.  by  Cleland,  D.  I.  and  King,  W.  H.,  pp.  '19-50,  McGraw-Hill, 
1969. 
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and  Rosenzweig,  define  a  system  initially  as: 

..."an  organized  or  complex  whole,  an  assemblage 
or  combination  of  things  or  parts  forming  a  complex 
or  unitary  whole."   The  term  system  covers  an  ex- 
tremely broad  spectrum  of  concepts. 7 

and  later  as: 

...an  array  of  components  designed  to  accomplish 
a  particular  objective  according  to  plan.   There 
are  three  significant  points  to  this  definition. 
First,  there  must  be  a  purpose,  or  objective,  which 
the  system  is  designed  to  perform.   Second,  there 
must  be  a  design  or  an  established  arrangement  of 
the  components.   Finally,  inputs  of  information, 
energy,  and  materials  must  be  allocated  according 
to  plan. 8 

Melvin  B.  Kline  and  Melvin  W.  Lifson,  in  lecture  notes 

prepared  for  a  System  Engineering  course  at  the  University 

of  California,  Los  Angeles,  define  a  system  as  follows: 

A  system  is  a  set  of  elements  organized  to  perform 
a  set  cf  designated  functions  in  order  to  achieve 
desired  results.   An  element  is  a  set  of  resources 
organized  to  perform  some  highly  interrelated  sub- 
set of  the  desired  system  functions.   The  resources 
which  comprise  an  element  include  personnel,  ma- 
terial, equipment,  facilities,  and  information. 9 

There  are  many  more  definitions  of  a  system  which  could 
be  presented.   However,  the  definitions  we  have  chosen  to 
include  appear  to  have  a  common  set  of  ideas  throughout. 
They  can  be  construed  to  include  the  assemblage  or  arrange- 
ment of  parts,  things,  components  or  elements  organized  into 


7 

Johnson,  R.  A.,  Kast,  F.  E.,  and  Rosenzweig,  J.  E., 

The  Theory  and  Management  of  Systems,  p.  4,  McGraw-Hill, 

Ibid. ,  p .  91  • 

^Kline,  M.  B.  and  Lifson,  M.  W. ,  System  Engineering, 
p.  1-14,  Lecture  Notes,  1970. 
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a  complex,  unitary  whole  or  structure.  Therefore,  for  pur- 
poses of  this  paper,  a  system  can  be  defined  to  include  the 
interaction,  interdependency  and  integration  of  the  combina- 
tion of  elements  into  a  unitary  whole  by  means  of  a  plan  to 
achieve  desired  results.  Obviously,  the  meaning  or  concept 
of  the  word  "system"  carries  with  it  a  much  greater  amount 
of  thought  and  in-depth  study  than  is  generally  realized. 

An  application  of  a  system  which  will  be  used  in  this 
paper  is  seen  in  the  Naval  laboratory  organization  which  can 
be  viewed  as  a  man-made  system  having  interaction  with  its 
environment  (i.e.  sponsor,  contractor,  workcenters,  special- 
ists, other  government  agencies,  etc.).   It  is  a  system  of 
interrelated  parts  working  in  conjunction  with  each  other 
in  order  to  accomplish  desired  results,  both  of  the  organisa- 
tion and  the  individuals . 

Now  that  the  term  "system"  has  been  defined  and  it  is 
understood  how  it  will  be  used  in  this  paper,  what  is  the 
systems  approach  to  management  or  the  systems  concept?   The 
systems  concept  is  more  widely  discussed  than  understood. 
It  has  been  widely  applied  by  people  who  did  not  know  they 
were  doing  so  and  has  often  been  ignored  by  people  who 
should  know  better. 

The  systems  approach  primarily  involves  the  idea  that 
every  organization  is  a  system  and  is  composed  of  many  in- 
terrelated parts,  all  of  which  affect  each  other  and  the 


Cleland,  D.  I.  and  King,  W.  H. ,  Systems ,  Organizations , 
Analysis,  Management:   A  Book  of  Readings,  p.  J<7,  McGraw-Hill, 
1959. 
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total  system  in  some  manner.   Therefore,  a  manager's  main 
concern  should  be  given  to  the  overall  effectiveness  of  the 
system  (rather  than  to  the  effectiveness  of  the  individual 
parts  or  subsystems)  and  to  the  inter-dependencies  of  the 
elements  of  the  system.   This  concept  can  be  applied  to  any 
organization  and  any  level  in  an  organization.   In  applying 
the  systems  approach,  overall  organizational  objectives  and 
goals  must  be  considered  rather  than  just  considering  the 
parochial  objectives  of  a  particular  subsystem.   The  manager 

must  consider  overall  objectives  and,  if  necessary,  make 

11 
decisions  which  are  sometimes  non-optimal  for  his  subsystem. 

This  does  not  imply  that  subsystems  will  always  be  non- 
optimized,  for  some  decisions  which  are  optimal  for  the 
total  system  will  also  be  optimal  for  the  subsystem. 

The  theory  of  systems  concepts  closely  relates  to  a 
general  theory  of  management  that  has  evolved.   It  focuses 
on  the  fundamental  processes  which  are  essential  for  any 
type  of  organization  —  business,  government,  educational, 

social  and  other  activities  —  where  human  and  physical 

12 
resources  are  combined  to  meet  certain  objectives.     These 

fundamental  processes  have  been  described  in  various  ways, 
but  the  four  basic  functions  of  planning,  organizing,  con- 
trolling and  communicating  have  received  general  acceptance. 


Ibta. 


1  ? 
"Johnson,  op.    cit.  ,  p.  l'l 
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Richard  Johnson,  et.    at.  ,  defines  them  in  terms  of  systems 

concepts  as  follows : 

Planning .   The  managerial  function  of  planning  is 
one  of  selecting  the  organizational  objectives  and 
the  policies,  programs,  procedures,  and  methods 
for  achieving  them.   The  planning  function  is  es- 
sentially one  of  providing  a  framework  for  inte- 
grated decision  making  and  is  vital  to  every 
man-machine  system. 

Organizing .   The  organizing  function  helps  to  co- 
ordinate people  and  resources  into  a  system  so  that 
the  activities  they  perform  lead  to  the  accomplish- 
ment of  system  goals.   This  managerial  function 
involves  the  determination  of  the  activities  re- 
quired to  achieve  the  objectives  of  the  enterprise, 
the  departmentation  of  these  activities,  and  the 
assignment  of  authority  and  responsibility  for  their 
performance.   Thus  the  organizing  function  provides 
the  inter-connection,  or  intertie,  between  the 
various  subsystems  and  the  total  organizational  sys- 
tem. 

Control .   The  managerial  function  of  control  is  es- 
sentially that  of  assuring  that  the  various  organi- 
zational subsystems  are  performing  in  conformance 
to  plans.   Control  is  essentially  the  measurement 
and  correction  of  activity  of  the  subsystems  to 
assure  the  accomplishment  of  the  overall  plan. 
Communication.   The  communication  function  is  pri- 
marily one  of  the  transfer  of  information  among 
decision  centers  in  the  various  subsystems  through- 
out the  organization.   The  communication  function 
also  includes  the  interchange  of  information  with 
the  environmental  forces. 13 

These  four  functions  should  not  be  considered  as  independent 

activities  nor  should  any  time  sequence  be  implied.   It  is 

part  of  the  systems  concept  to  realize  how  interlocked  they 

are.   Another  list  of  the  functions  of  management  is  plan- 

1*1 

ning,  organizing,  staffing,  directing  and  controlling. 

Whatever  terms  are  used,  the  advantage  of  approaching  any 


13Ibid.,    pp.  14-15 


Koontz,  H.  and  O'Donnoll,  C,  Principles  of  Management 
An  Analysis  of  Managerial  Functions,  pp.  ;IY-Jt9>  McGraw-Hill, 
1972. 
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area  or  problem  as  a  system  so  the  critical  variables  and 
constraints  and  their  interaction  with  each  other  can  be 
seen  is  obvious.   "It  forces  scholars  and  practitioners  in 
the  field  to  be  constantly  aware  that  one  single  element, 

phenomenon,  or  problem  should  not  be  treated  without  regard 

IS 
for  its  interacting  consequences  with  other  elements." 

This  is  exemplified  in  the  case  of  the  four  managerial 
functions  or  processes. 

The  planning,  organizing,  controlling  and  communicating 
functions  form  the  structure,  means,  measure  and  environment 
of  the  decision-making  process.   Management  is  basically  the 
coordination  and  integration  of  all  resources  (both  human 
and  technical)  to  accomplish  specific  results.     The  total 
management  process  includes  coordinating  the  functions  so 
as  to  meet  the  overall  objectives  of  the  system.   Therefore, 
the  systems  approach  also  involves  coordinating  and  inte- 
grating the  management  functions  of  planning,  organizing, 
controlling  and  communicating  in  .a  systematic  manner. 

C.   CURRENT  THOUGHTS  ON  THE  SYSTEMS  APPROACH 

The  systems  concept  has  been  in  existence  for  many 
years;  but  in  the  past  decade,  a  general  systems  theory  has 


1<5Ibid.}    p.  14. 

Scanlan,  B.  K.,  Principles  of  Management  and  Organi- 
zational Behavior,  p.  5,  John  Wiley  &  Sons,  197  3. 
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been  developed  to  provide  a  basis  for  the  integration  of 
managerial  techniques  and  scientific  knowledge  across  a 
broad  spectrum. 

In  one  of  the  more  current  texts  on  the  systems  con- 
cept, Edgar  Huse  and  James  Bowditch  address  the  subject 

from  three  perspectives  —  the  structural-design  view  of 

17 
management j  work  flow  and  the  human  perspective.     Regard- 
less of  the  perspective,  the  organization  is  treated  as  an 

-1  o 

open  system   which  affects  and  is  affected  by  its  environ- 
ment.  The  inter-dependencies  among  the  subsystems  are  as 
important  as  the  individual  subsystem.   Organizations  try 
to  achieve  a  balance  among  the  subsystems,  but  the  balance 
is  continually  changing  with  the  need  to  adapt  to  an  un- 
stable environment  and  the  inter-dependence  of  the  parts. 
The  organization  must  be  viewed  from  all  three  perspectives 
(as  formal  organizations,  as  flow  systems  and  as  interacting 

humans)  for  a  complete  understanding.   To  use  the  systems 

19 
approach,  it  is  necessary  to  integrate  these  perspectives. 

Another  view  of  the  systems  concept  which  is  more 

engineering/problem  solving  oriented  is  in  the  field  of 

systems  engineering. 


17 

Huse,  E.  P.  and  Bowditch,  J.  L.,  Behavior  in  Organ- 
izational Behavior,  p.  5,  John  Wiley  &  Sons,  1973- 

-i  o 

A  system  is  an  "open  system"  when  there  are  constant 
relationships  to  its  environment,  or  inputs  from  the  en- 
vironment and  outputs  to  the  environment. 

19 
Huse,  op.    ait.,    pp.  '1^-^15. 
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Experience  has  shown  that  the  successful  planning 
and  acquisition  of  large  complex  systems  requires 
the  "systems  approach."   The  systems  approach 
recognizes  the  interrelationships  which  tie  a  sys- 
tem together;  it  recognizes  that  factoring  out  a 
part  of  a  problem  by  neglecting  the  interactions 
among  subsystems  and  components  increases  signifi- 
cantly the  probability  that  a  solution  to  the  prob- 
lem will  not  be  found;  it  requires  that  the 
boundaries  of  the  system  be  extended  outward  as 
far  as  is  required  to  determine  which  interrela- 
tionships are  significant  to  the  solution  of  the 
problem. 20 

This  systems  engineering  view  was  generated  in  part  by  in- 
adequacies of  military  system  acquisition  and  operation 

and  considers  systems  engineering  as  the  application  of  the 

21 

systems  approach.     In  this  paper,  a  broader  view  of  the 

systems  approach  is  taken  and  it  is  considered  as  more  of 
a  management  philosophy  than  a  problem  solving  or  engineer- 
ing technique. 

Another  view,  presented  by  Richard  Johnson,  et.    at. , 
of  the  systems  concept  is  to  describe  the  flow  process, 
analyze  each  segment  and  explore  relationships  of  parts  to 

the  whole.   In  this  way,  subsystems  which  fail  to  optimize 

22 
their  contribution  to  the  total  system  can  be  recognized. 

This  view  thinks  of  the  organization  as  an  integrated  whole 

where  each  subsystem  or  part  is  associated  with  the  total 

operation  and  its  structure  is  created  by  many  subsystems 


20 

Kline,  op.    ait.,    p.  1-12 

Ibid.  y    p .  1-13 • 

22 

Johnson,  op.    cit . y    p.  90 
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arranged  in  hierarchial  order.   The  output  of  the  lower  sub- 

systems  is  input  for  higher  subsystems,  which  is  input  for 

23 
the  next  higher  level,  etc. 

In  this  paper,  the  systems  concept  is  viewed  as  a  useful 
way  of  thinking  about  the  job  of  managing.   It  provides  a 
framework  for  visualizing  environmental  factors  and  allows 
recognition  of  the  functions  of  subsystems.   Systems  in 
which  managers  function  are  complex  and  the  systems  concept 
fosters  a  way  of  thinking  which  helps  clear  up  some  of  the 
complexity  while  at  the  same  time  helps  the  manager  recog- 
nize the  nature  of  complex  problems  so  he  can  better  oper- 

24 
ate  within  the  system.     It  is  important  to  recognize  that 

every  organizational  system  is  part  of  a  larger  system  with 

which  it  interacts  and  influences,  and  that  all  systems  are 

in  a  constant  state  of  change  —  they  are  created,  operated, 

25 
revised  and  sometimes  eliminated. 

D.   THE  TOTAL  SYSTEM  APPROACH 

The  "total  system  approach"  is  basically  a  philosophy 
or  concept  of  management.   The  management  can  involve  sys- 
tems engineering,  business  management,  developmental  en- 
gineering or  project  management,  to  name  a  few.   Regardless 


23Ibid.J    p.  91. 

2k 

Johnson,  R.  A.,  Kast,  F.  E.  and  Rosenzweig,  J .  E . , 

"Systems  Theory  and  Management,"  in  Emerging  Concepts  In 

Management ,  ed .  by  Wortman,  M."  S.,  Jr.  and  Luthans,  F., 

p.  331,  Macmillan,  1969. 


25Ibid. 
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of  the  area  or  discipline  in  which  it  is  used,  it  is  a 
way  of  thinking  or  philosophy  for  a  manager  rather  than  a 
list  of  techniques 5  principles,  "recipe  book"  or  body  of 
knowledge . 

It  is  a  concept  which  provides  the  manager  with  a  frame- 
work he  should  use  to  visualize  the  system  in  which  he  op- 
erates and  the  manner  in  which  his  area  of  responsibility 
is  constrained  and  influenced.   It  recognizes  the  systems 
concept  and  the  complex  interrelationships  which  exist  in 
every  organization  of  subsystems.   If  understood  by  the 
manager,  it  will  help  to  remove  some  of  the  complexity  of 
his  job  on  the  one  hand;  and  on  the  other,  help  him  to 
recognize  the  very  complex  nature  of  the  structure  within 
which  he  worKs. 

Some  authors  have  implied  that  the  concept  of  "general 
systems"  has  been  translated  into  "total  systems."   While 
general  systems  theory  is  a  valid  concept  because  its  pro- 
ponents realize  its  limitations,  the  total  systems  concept 
is  not  valid  because  it  cannot  explain  the  way  things  are 
or  predict  the  way  things  are  going  to  be  (regarding  the 
most  significant  aspect  of  the  organization,  people). 
However,  the  meaning  of  the  term  "total  system"  as  used  here 
is  not  intended  to  imply  a  specific  systems  analysis  tech- 
nique or  management  information  system  which  will  solve  all 


Brooker,  op.    oil.,    p.  365 
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the  problems  which  a  manager  encounters  or  predict  problems 
which  will  arise.   Rather,  total  system  implies  a  management 
outlook  which  is  oriented  toward  the  goals  and  objectives 
that  have  been  established  for  the  whole  or  total  system. 
To  use  the  total  system  approach,  the  manager  must  be 
able  to  see  beyond  the  immediate  consequences  of  any  de- 
cision or  change  which  he  makes  in  his  subsystem  of  the  or- 
ganization.  No  one  subsystem  of  an  organization  can  function 
effectively  without  others  and  any  action  taken  by  one  will 

have  effects  which  can  be  traced  throughout  the  total  sys- 

27 

tern.     When  a  manager  makes  a  decision  with  no  thought  of 

its  effect  on  other  parts  of  the  organization  or  the  organi- 
zation as  a  whole,  he  is  not  using  the  total  system  approach 
as  viewed  here . 

In  the  following  chapter,  the  Naval  Electronics  Labora- 
tory, Center  '  s  mission,  personnel,  funding,  organization, 
manager  roles,  conflicts  and  interfaces  will  be  presented 
in  order  to  gain  a  clearer  understanding  of  why  and  how  the 
system  approach  might  be  used  by  laboratory  project  managers. 
Chapter  IV  presents  the  history  of  project  management,  NELC 
project  management,  NELC  project  manager's  profile,  some 
examples  of  problems  encountered  in  planning  and  control- 
ling and  examples  of  use/nonuse  of  the  systems  approach. 
Throughout  the  discussion  which  follows,  the  systems  concept, 


27 

Cleland,  Management ,  p.  1'I2. 
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or  making  decisions  (whether  planning  or  control  decisions) 
in  the  light  of  their  effect  on  other  subsystems  in  the 
organization,  must  be  kept  in  mind.   Understanding  the  com- 
plexity of  the  Naval  laboratory ,    the  many  interfaces  with 
which  the  project  manager  must  deal  and  some  of  the  problems 
encountered  should  make  the  value  of  the  systems  approach 
to  management  clear. 


2 'I 


III.   THE  NAVAL  ELECTRONICS  LABORATORY  CENTER 

A.   INTRODUCTION 

Government  laboratories  can  trace  their  history  to  the 
establishment  of  the  Springfield  Arsenal  in  1790.   Over  the 
years  Naval  laboratories  have  played  a  major  role  in  the 

development  of  weapons  systems  and  have  been  responsible 

?8 

for  technological  advances  in  many  areas. 

Today,  the  prime  mission  of  the  Naval  Electronics  Labo- 
ratory Center  (NELC)  is  to  be  the  principle  Navy  Research, 
Development,  Test  and  Evaluation  center  for  electronics 
technology  and  command,  control  and  communication  concepts 
and  systems.   More  specifically,  it  is  the  primary  in-house 
research  and  development  capability  for  the  following: 

•  Navy  and  Marine  Corps  systems,  subsystems  and 
technologies 

•  command,  control  and  communications 

•  electromagnetic  surveillance,  identification  and 
navigation 

•  electronic  warfare 

•  shipboard  internal. communications 

•  Information  collection,  processing,  transmission  and 
display 

•  computer  and  software  technology 

•  automatic  test  and  monitoring  equipment 


For  a  complete  treatment  of  Naval  laboratory  history 
see  Munro,  W.  S.  and  Brennan ,  A.  C,  Project  Management  as 
Related  to  Weapons  Development  in  Navy  Research  and  Develop- 
ment Organizations,  Master's  Thesis,  Naval  Postgraduate 
School,  Monterey,  California,  197  3. 
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electro-optics  and  optics 

electronic  materials,  components  and  circuits 

electromagnetic  propagation 

antennas  and  antenna  systems 

human  factors  technology 

electronic  systems  effectiveness  engineering 

bioelectronics . 
The  Naval  Electronics  Laboratory  includes  over  eighty 
military  personnel  and  fifteen  hundred  civilian  personnel. 
More  than  three  hundred  of  these  hold  advanced  degrees  and 
the  proportion  of  advanced  degrees  has  increased  over  the 
years.   (Figure  1  gives  an  NELC  educational  profile  from 
fiscal  year  69  through  '(k.)      Approximately  one-half  of  ail 
NELC  personnel  are  professionals.   Figure  2  gives  examples 
of  NELC  professionals  along  with  its  professional  mix. 
The  laboratory  is  under  the  Navy  Industrial  Funding 
System  and  operates  much  like  an  individual  business  enter- 
prise, with  complete  accountability  to  its  customer  and 
Navy  fiscal  management.   All  funds,  with  few  exceptions, 
are  received  from  sponsors  as  the  result  of  successful  pro- 
ject bidding  in  competition  with  other  research  and  develop- 
ment organizations.   The  exceptions  are  military  construction 
funds  and  a  small  amount  of  equipment  and  minor  construction 
and  repair  funds  provided  by  the  Director  of  Laboratory 
Programs.   The  laboratory  fiscal  73  budget,  for  example, 
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totaled  over  $123  million.   Figure  3  shows  the  history  of 
NELC  funding  by  RDT&E  categories. 

To  .  aid   in   understanding  the  role  played  by  the  lab- 
oratory project  manager  in  equipment  acquisition,  this  ■ 
chapter  presents  the  NELC  organization,  manager  roles,  con- 
flicts and  interfaces . 

B.   ORGANIZATION 

The  traditional  method  of  organizing  has  been  functional 
departmentalization.  This  method  utilizes  a  top-to-bottom 
model  with  departments  such  as  engineering,  administrative 
support,  etc.  responsible  to  one  manager.  However,  if  the 
emphasis  in  an  organization  is  on  contract  work  where  the 
workload  is  composed  of  various  projects  with  specific  ob- 
jectives and  well-defined  points  of  completion,  then  pro- 

.   +.       ....  .  .   30 

ject  organization  is  more  appropriate. 

NELC  has  need  for  both  the  functional  and  the  project 
organizational  models  and  therefore  operates  within  a  ma- 
trix organization  (Figure  4).   "The  matrix  organization 
is  the  realization  of  a  two-dimensional  organization  which 
emanates  directly  from  the  two  dimensions  of  authority. 
Two  complementary  organizations  —  the  project  organization 
and  the  functional  organization  —  are  merged  to  create  the 
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Naval  Electronics  Laboratory  Center  Digest,  prepared 

by  NELC  Planning  Office,  30  June  1973. 
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Cleland,  Management ,  p.  337  - 
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31 
matrix  organization."    This  type  organization  is  ideally 

suited  as  the  NELC  operating  structure,  for  NELC  is  basi- 
cally two  dimensional. 

The  Command  Control  and  Communications  Program  Depart- 
ment (Figure  5)  contains  seven  major  programs  (e.g.  Shore 

Systems  -  1100,  Surface  Systems  -  1200,  etc.)  "which  are 

32 

externally  sponsored.     Each  major  program  in  the  Command 

Control  and  Communications  Department  contains  numerous 
smaller  projects  (e.g.  World  Wide  Military  Command  Control 
System  -  1130  under  the  Shore   Systems  Program  and  the 
Minimum  Essential  Emergency  Communication  Network  Project  - 
1320  under  the  Submarine  Systems  Program)  which  are  headed 
by  a  project  manager.   The  projects  within  the  Command 
Control  and  Communications  Program  Department  comprise  ap- 
proximately one-half  of  all  NELC  projects  and  are  tasked 
and  funded  primarily  by  the  Naval  Systems  Commands.   The 
projects  in  turn  task  and  fund  the  five  functional  depart- 
ments (along  with  some  outside  contractors  and  other  labo- 
ratories) for  a  specific  requirement  or  level  of  effort. 
The  project  offices  are  organized  functionally  and  may  con- 
tain only  a  few  code  1000  personnel  who  are  primarily  re- 
sponsible for  managing  the  overall  project.   An  example 
of  a  Command  Control  and  Communications  Programs  Department 


31Ibid. ,    p.  339. 
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For  purposes  of  this  paper  "externally  sponsored" 

refers  to  any  project  which  is  funded  directly  from  a  source 

outside  the  laboratory  organization. 
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project  is  the  World  Wide  Military  Command  Control  System 
(WWMCCS)  project  organization  depicted  in  Figure  6.   The' 
project  organization  of  the  Command  Control  and  Communica- 
tions Programs  Department  is  the  first  dimension  of  the 
two-dimensional  matrix  organization. 

The  second  dimension  of  the  NELC  organization  is  seen 
in  the  five  functional  departments  of  Electromagnetics 
Technology,  Information  Technology,  Engineering  Sciences, 
Computer  Sciences  and -Administrative  and  Technical  Support 
Each  functional  department  is  further  organized  into  func- 
tional areas  of  specialization  and  appropriate  staffs 
(Figure  7).   The  technology  and  sciences  departments  main- 
tain some  of  their  own  projects  which  are  externally  spon- 
sored while  at  the  same  time  acting  as  primary  support  for 
the  Command  Control  and  Communications  Programs  Department 
projects.   When  a  functional  department  is  performing  a 
task  for  a  Command  Control  and  Communications  Programs 
Department  project,  a  task  leader  is  designated  within  the 
functional  department  and  has  primary  responsibility  for 
the  completion  of  the  required  task  or  level  of  effort. 
The  task  leader  maintains  close  contact  with  the  project 
manager  through  frequent  conversations  and  weekly  mile- 
stone/project review  meetings.   When  a  functional  depart- 
ment has  externally  sponsored  projects,  a  project  manager 
is  designated  within  the  department  and  has  control  of  the 
entire  project. 
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Figure  7.   Typical  Functional  Department  Organization, 
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C.   MANAGEMENT  ROLES  AND  THE  SYSTEMS  APPROACH 
1.   Functional  Managers 

The  functional  manager  and  project  manager  have 
different  views  of  the  organization.   The  functional  man- 
ager is  primarily  responsible  for  a  particular  function  or 
technology  within  the  organization  and  for  providing  in- 
formation and  skills  on  the  "state-of-the-art"  in  his  dis- 
cipline.  In  addition,  he  must  support  projects  in  the 
organization  which  require  his  knowledge  and  skill.   How- 
ever, he  is  not  responsible  to  the  project  office  for  per- 
formance but  is  responsible  through  the  chain  of  command 
for  his  particular  department  or  subsystem  within  his  de- 
partment.  Consequently,  it  is  natural  for  him  to  become 
parochial  in  his  viewpoint.   If  not  carried  to  an  extreme, 
this  is  a  desirable  situation  for  it  tends  to  protect  the 
integrity  of  existing  specialized  areas.   The  functional 
manager  may  however,  become  so  wrapped  up  in  his  own  area 
of  specialization  that  he  comes  to  consider  his  function 
as  the  only  important  one  —  at  the  expense  of  other  parts 
of  the  organization  or  overall  organizational  objectives. 

In  the  very  human  desire  to  do  a  good  job, 
the  functional  manager  tends  to  develop 
"tunnel  vision,"  which  allows  him  to  see 
things  only  within  the  narrow  scope  of  his 
function  and  to  conveniently  ignore  the 
"bigger  picture" ...  An  often-heard  gripe  in 
a  variety  of  different  organizations  is  that 
the  organization  seems  to  be  run  for  the 
benefit  of  the  accounting  department  or  the 
elevator  operators  rather  than  to  enhance 
the  opportunity  to  achieve  overall  objec- 
tives.  This  Is  a  natural  out-growth  of 
over-zealous  functional  .management .   Since 
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the  responsibilities  of  the  functional  man- 
ager are  limited  to  his  area,  he  seeks  to 
make  that  area  as  efficient  and  effective 
as  possible  —  often  without  regard  to  the 
effect  of  his  actions  on  other  functions  or, 
more  importantly,  on  the  basic  tasks  which 
the  overall  organization  must  perform. 33 

Although  this  loss  of  the  "big  picture"  or  not  using  the 
systems  approach  may  become  a  problem  in  functional  depart- 
ment management,  it  is  not  as  critical  a  situation  for  the 
functional  manager  as  it  is  for  the  project  manager. 
2 .   Project  Managers 

The  project  manager  is  truly  a  general  manager.   He 
must  have  the  "big  picture"  and  view  his  project  and  the 
organization  in  a  perspective  which  will  allow  him  to  con- 
sider the  performance,  cost  and  schedule  aspects  of  his 
project.   At  the  same  time  he  must  motivate  diverse  groups 
toward  a  common  goal  or  objective  for  his  project  while 
keeping  in  mind  the  goals  of  the  total  system.   Although 
the  project  manager  normally  operates  at  a  relatively  low 
level  in  the  NELC  organization  (i.e..  fifth  level  below  the 
Technical  Director)  "he  must  perform  the  same  general 
management  functions  as  do  top  managers  —  he  must  integrate 

the  efforts  of  a  variety  of  functional  managers  to  accom- 
pli 
plish  the  goals  of  the  project  and  the  organization." 

He  must  have  a  basic  understanding  of  all  the  functional 


-^Cleland,    Management ,    pp.    3ztO-3JH 

3  'I 

3  Ibid,  j    p.    3'I2. 
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areas  and  realize  the  importance  of  each  in  the  accomplish- 
ment of  overall  objectives.   If  he  gets  "tunnel  vision"  and 
the  attitude  that  all  other  projects  and  functions  are  less 
important  than  his  own,  he  may  be  in  a  position  to  upgrade 
his  project  at  the  expense  of  others  and  possibly  at  the 
expense  of  the  total  system.   The  project  manager  must  use 
the  systems  approach. 

D.   MANAGEMENT  CONFLICT 

Conflict  between  the  functional  manager  and  the  project 
manager  is  a  natural  outgrowth  of  the  matrix  organization. 
The  project  and  functional  managers  maintain  a  relationship 
similar  to  a  buyer/seller  relationship  with  their  respec- 
tive organizational  elements  having  conflicting  objectives. 
The  project  manager's  first  objective  is  to  obtain  satis- 
factory performance  and  schedule  at  the  lowest  possible 
cost  to  the  project.   The  functional  manager  naturally 
wants  what  is  best  for  his  particular  subsystem  within  the 
organization  and  must  divide  his  resources  among  various 
projects.   "The  project  and  functional  managers  are  thereby 
involved  in  a  deliberate  and  purposeful  conflict  within  the 
organization. "  J 

If  both  managers  use  the  systems  approach  or  think  in 
terms  of  the  total  system,  this  conflict  is  beneficial  to 
the  objectives  of  the  organization  as  a  whole.   The  project 


35Ibid. 
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and  functional  manager  must  understand  each  others  problems, 
constraints,  goals  and  objectives  in  order  to  maintain  an 
atmosphere  of  cooperation  and  compromise.   If  however,  the 
manager  views  his  subsystems  as  the  only  important  one  and 
always  works  to  optimize  its  objectives,  conflicts  will  in- 
crease and  may  need  to  be  resolved  at  a  common  supervisor 
level  in  the  organization.   For  example,  at  NELC  if  the 
WWMCCS  Project  Manager  and  a  functional  manager  in  the  Ap- 
plication Software  Division  of  the  Computer  Sciences  De- 
partment could  not  reach  agreement  as  to  which  engineer  was 
to  be  assigned  to  work  on  the  WWMCCS  Project,  theoretically, 
the  lowest  common  supervisor  at  which  the  conflict  could  be 
resolved  would  be  the  Technical  Director  (Figure  8).    In 
practice,  this  would  probably  net  happen  for  the  conflict 
would  be  resolved  at  a  lower  level  (i.e.  the  project  man- 
ager's superior  and  the  functional  manager's  superior  might 
discuss  the  problem,  make  a  decision  and  pass  it  down  to 
the  project  and  functional  managers  .without  allowing  the 
conflict  to  go  any  higher  in  the  organization) . 

Other  conflicts  arise  involving  promotion  of  personnel, 
personnel  tasking,  resource  allocation  and  priorities.   When 
these  conflicts  develop,  a  willingness  on  the  part  of  the 
functional  and  project  managers  to  negotiate  is  essential 
to  the  proper  functioning  of  the  matrix  organization.   These 
problems  are  further  developed  in  Chapter  IV. 
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E.   INTERFACES 

1.   External  Interfaces 

The  range  of  external  Interfaces  which  are  re- 
quired by  NELC  in  day  to  day  operations  is  much  too  wide  and 
varied  to  investigate  in  detail.   However,  some  interfaces 
which  are  the  most  pertinent  to  NELC  project  managers  will 
be  presented. 

The  most  important  external  interface  for  NELC  and 
individual  project  managers  are  with  Naval  Systems  Commands. 
Systems  Commands  (e.g.  NAVELEX,  NAVSHIPS,  NAVAIR,  etc.) 
sponsor  projects  which  are  the  primary  source  of  funds  for 
NELC  operations.   There  are  many  formal  and  informal  inter- 
faces with  the  Systems  Commands  which  are  carried  on  in 
various  ways.   For  example,  the  WWMCCS  Project  Office  in 
the  Command  Control  and  Communications  Programs  Department 
was  established  when  NAVELEX  informed  NELC  of  their  require- 
ment through  a  task  statement.   A  rough  estimate  of  the  task 
cost  and  schedule  was  prepared  by  NELC.   NAVELEX  then  di- 
rected NELC  to  prepare  a  task  summary  which  included  items 
such  as  a  task  description,  a  funding  summary,  subtask 
descriptions,  Quality  Assurance  requirements,  Integrated 
Logistic  Support  considerations,  test  and  evaluation  re- 
quirements, etc.   NAVELEX  and  NELC  then  negotiated  cost, 
schedule  and  performance  requirements  prior  to  NAVELEX  ac- 
ceptance of  the  NELC  prepared  task  summary.   Once  the  task 
summary  was . accepted ,  it  was  comparable  to  a  contract  be- 
tween NAVELEX  and  NELC. 
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In  the  initial  phases  of  project  establishment 
just  described,  there  are  many  NELC  and  sponsor  personnel 
and  disciplines  involved  in  the  planning  interface  between 
NELC  and  the  sponsor.   Once  the  project  is  established 
there  is  one  individual  as  the  primary  point  of  contact  in 
the  Systems  Command  that  interfaces  with  the  NELC  project 
manager,  but  the  project  manager  frequently  must  deal  with 
other  sponsor  personnel  in  areas  such  as  funding,  Integrated 
Logistic   Support,  etc. 

Not  all  NELC  projects  are  sponsored  in  the  Naval 
Systems  Commands  (Figure  9).      Approximately  one  quarter  of 
NELC  projects  are  sponsored  by  other  sources  such  as  the 
Director  of  Laboratory  Programs,  the  Marine  Corps,  other 
Navy  sources,  other  Department  of  Defense  sources  and  other 
government  sources  (Figure  10  contains  examples  of  non-Navy 
sponsored  programs  in  fiscal  73).   Each  of  these  projects 
requires  the  same  basic  interfaces  as  Systems  Command  spon- 
sored projects . 

Another  important  external  Interface  for  NELC  pro- 
ject managers  is  in  the  area  of  commercial  contractor  sup- 
port.  One  of  the  primary  sources  of  project  support  comes 
from  external  sources  (e.g.  the  MEECN  Project  relied  upon 
contractor  support  for  approximately  twenty-five  percent 
of  its  tasks).   If  a  project  requires  support  in  a  particu- 
lar area  which  is  not  available  from  a  NELC  functional  de- 
partment or  can  be  obtained  at  a  better  cost  and  schedule 
from  a  contractor,  the  project  manager  may  develop  a 
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relationship  with  a  commercial  contractor  in  order  to 'obtain 
the  necessary  support  for  his  project.   In  addition,  the 
Administration  and  Technical  Support  Department,  through 
the  Supply  and  Contract  Services  Division,  will  interface 
with  the  Navy  Regional  Procurement  Office,  Long  Beach  in 
contracting  for  the  required  support.     This  interface  is 
further  discussed  in  Chapter  IV. 

The  "fleet"  is  another  external  interface  with  which 
NELC  must  maintain  close  contact.   As  the  user  of  NELC  de- 
veloped equipment,  the  fleet  necessarily  provides  inputs  to 
project  offices.   These  are  sometimes  direct  inputs  to  the 
project  office  through  a  fleet  liaison  staff  and  are  some 
times  indirect  inputs  through  the  Systems  Command  sponsor. 
For  example,  the  WWMCCS  project  organization  contains  a 
Fleet  Liaison  Staff  which  maintains  direct  contact  with 
fleet  units  concerned  with  the  project.   Another  example  of 
a  fleet  interface  is  the  test  and  evaluation  of  laboratory 
developed  prototypes  conducted  in  operational  commands  by 
laboratory  personnel. 

The  Naval  laboratory  and  the  projects  within  it 
maintain  many  other  external  interfaces  which  have  varying 
degrees  of  importance  to  the  organization.   A  few  examples 
include:   professional  meetings  in  technical  areas,  seminars 


•3  C 

-*  NELC  has  purchase  authority  of  $2,500  for  routine 
requirements  and  $10,000  for  emergencies.   Any  requirement 
which  exceeds  these  thresholds  must  go  through  NRPO  Long 
Beach . 
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with  industry j  management  consultant  groups,  educational 
institutions  and  other  laboratories . 
2 .   Internal  Interfaces 

The  NELC  matrix  organization  chart  indicates  that 
the  project  manager  must  maintain  many  internal  interfaces 
throughout  the  system.   His  primary  interface  with  the 
technical  functional  departments  is  with  the  task  leader 
who  is  assigned  in  the  functional  department  to  work  on  a 
given  task  for  his  project.   In  the  personnel  area,  the 
project  manager  has  little  direct  influence  as  to  the  choice 
of  Individuals  assigned  to  his  project  within  a  functional 
department  (i.e.  the  functional  division  head  knows  his 
personnel,  what  type  project  each  is  best  suited  for,   man- 
ages his  resources  to  support  many  projects  and  is  the  line 
authority  for  functional  task  leaders).   However,  the  pro- 
ject manager  will  sometimes  "politic"  to  influence  the 
assignment  of  a  certain  key  individual  when  he  has  definite 
feelings  that  the  individual  and  task  are  well  matched. 

The  project  manager  must  also  work  closely  with 
Administrative  and  Technical  Support  Department  personnel, 
particularly  in  the  Supply  and  Contract  Services  Division. 
If  his  project  requires  support  from  commercial  contractors, 
the  project  manager  must  maintain  a  close  relationship  with 
contract  specialists  in  the  Supply  and  Contract  Services 
Division  to  ensure  that  the  required  items  in  the  procure- 
ment package  (Figure  11)  are  properly  prepared  and  sufficient 
lead  time  is  allowed  to  prevent  project  schedule  slippages. 
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Many  projects  interface  directly  with  the  staffs 
which  come  under  the  Deputy  Technical  Director  (Figure  8). 
These  staffs  include  such  areas  as  systems  analysis,  Quality 
Assurance,  advanced  technologies  and  planning;  and  are  used 
to  varying  degrees  by  different  projects.   For  example,  the 
WWMCCS  Project  Office  utilizes  analysis  personnel  (Code  230) 
as  integral  parts  of  its  organization. 

Finally,  an  important  internal  interface  which  must 
be  maintained  in  any  organization  is  the  line  authority 
chain  of  command  within  each  department.   The  project  man- 
ager is  working  for  two  bosses,  his  project  sponsor  and  his 
superior  in  the  department  chain  of  command.   The  interface 
with  his  chain  of  command  superior  concerns  the  areas  of 
internal  procedures,  personnel  assignments,  reports  and  any 
dealings  up  or  down  the  chain  of  command.   However,  the 
fact  that  the  project  manager  often  feels  obligated  to  sat- 
isfy his  project  sponsor  first  and  his  department  superior 
second,  is  a  good  example  of  the  "golden  rule"    in  project 
management . 


•57 

The  man  with  the  gold  makes  the  rules. 
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IV.   THE  PROJECT  MANAGER  IN  THE  SYSTEM 

A.   INTRODUCTION 

A  project  manager  and  a  project  sponsor  were  on  a  hunt- 
ing trip.   One  morning  the  sponsor  woke  up  early  and  went 
into  the  brush  to  get  a  lead  on  a  bear  which  was  reported 
to  be  in  the  area.   The  project  manager  was  about  to  join 
him  companion  when  he  heard  two  shots  and  a  blood  chilling 
roar.   His  friend  came  running  toward  the  tent  yelling, 
"Open  the  flap!  Open  the  flap!"   Just  as  the  project  man- 
ager opened  the  flap,  the  sponsor  ran  into  the  tent  chased 
by  a  huge  bear  not  twenty  yards  behind  him.   As  the  sponsor 
ran  through  the  tent  and  out  the  back  he  shouted,  "You  take 
care  of  this  one  while  I  bring  in  another  one!" 

This  chapter  is  concerned  primarily  with  the  man  in  the 
tent j  the  project  manager.   The  problems  which  confront  the 
project  manager  in  the  Naval  laboratory  are  many  and  varied. 
In  the  previous  chapter  some  general  problems  and  inter- 
faces with  which  he  must  contend  were  discussed.   In  this 
chapter  the  history  of  project  management,  NELC  project 
manager's  profile,  planning  and  control  problems  and  use  of 
the  systems  approach  will  be  discussed.   The  problems  and 
techniques  presented  are  generally  applicable  to  project 
managers  in  a  matrix  organization  regardless  of  size  or 
type  of  project.   Many  problems  which  are  discussed  were 
contributed  by  the  project  managers  who  were  interviewed  and 
some  are  inherent  in  a  matrix  organization.   The  project 
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managers  and  associated  personnel  interviewed  are  not  quoted 
directly,  but  some  of  the  thoughts  and  words  used  are  para- 
phrases and  composites  of  the  remarks  of  several. 

B.   HISTORY  OF  PROJECT  MANAGEMENT 

The  origin  of  project  management  can  be  traced  to  World 

TO 

War  II  and  the  Manhattan  Project  in  1942.     The  concept  of 
project  management  has  evolved  and  changed  over  a  number  of 
years  and  may  have  been  called  by  different  titles  in  ear- 
lier usage.   The  technique  of  project  management  today  is 
viewed  in  the  Department  of  Defense  as  a  means  to  deal  with 
the  problems  experienced  in  the  acquisition  of  weapon 
systems . 

The  prime  mover  in  the  evolution  of  project  management 
was  the  technological  revolution  which  made  possible  the 
complex  systems  of  today.   The  technology  which  initiated 
the  Manhattan  Project  was  the  nuclear  physics  of  Albert 
Einstein.   Although  the  Manhattan  Project  had  an  extremely 
high  wartime  priority,  success  may  not  have  come  so  rapidly 
(project  initiation  to  first  bomb  in  three  years)  without 
the  use  of  good  project  management  techniques. 

In  addition  to  the  Manhattan  Project,  defense  require- 
ments for  large  quantities  of  complex  systems  forced  indus- 
try to  look  for  new  ways  to  manage  development  and  production 
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The  Manhattan  Project  was  the  effort  to  develop  the 
first  atomic  bomb. 
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Difficulties  involved  in  obtaining  new  weapons  in  a  reduced 
amount  of  time  created  difficult  management-type  problems. 
Industry  looked  to  project  management  as  one  possible 
solution. 

The  military  services  have  used  some  form  of  project 
management  techniques  since  the  mid-1950 's.   The  Air  Force 
created  the  Ballistic  Missle  Division  with  the  responsi- 
bility of  managing  the  Atlas,  Thor  and  Titan  programs;  the 
Navy  organized  the  Special  Projects  Office  for  management 
and  development  of  the  Polaris  missle;  and  the  Army  es- 
tablished the  Army  Ballistic  Missle  Agency  to  develop  the 
Jupiter  missle.   Each  of  these  organizations  had  similar- 
ities that  indicated  a  need  for  special  management  tech- 
niques.  Each  program  was  given  high  priority  within  the 
services  and  had  first  choice  of  personnel,  authority  over 
support  organizations j  exemption  from  normal  procurement 
procedures,  access  to  top  officials  and  special  funding. 
A  project  manager  was  selected  and  provided  with  special 
authority  over  personnel,  materials,  facilities  and  funds. 
These  were  important  projects  and  contributed  significantly 
to  the  evolution  of  project  management  in  the  military. 

By  1961  the  techniques  of  project  management  had  been 
applied  to  many  acquisitions  other  than  missies  within  the 
services.   However,  there  was  a  wide  range  of  policies  and 
procedures  used  from  one  service  to  the  next  and  within 
each  service.   A  task  force  was  formed  to  study  acquisition 
methods  throughout  the  services  with  emphasis  on  project 
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management  techniques.   The  result  of  the  study  was  a  set 
of  recommendations  which  included:   more  extensive  use  of 
project  management  techniques  as  found  in  the  Air  Force  and 
Navy j  use  of  Program  Evaluation  and  Review  Technique  (PERT) 
should  be  encouraged,  more  work  should  be  done  in  the  area 
of  delegation  of  powers  to  project  managers  and  all  services 
should  employ  a  common  management  technique  for  use  in 
acquiring  complex  weapon  systems . 

Interest  in  project  management  continued  to  increase 
throughout  the  1960's  with  conferences,  studies  and  courses 
on  project  management  techniques  in  the  Department  of 
Defense.   In  May,  1965,  DoD  Directive  5010.4,  "System/Pro- 
ject Management"  attempted  to  pull  the  services  together  in 
their  efforts  to  manage  projects.   The  Directive  was  intended 
for  major  designated  projects  and  covered  mandatory  and 
nonmandatory  application  of  project  management  techniques 
and  procedures.   Major  system  acquisition  in  the  Department 
of  Defense  has  continued  to  require, the  use  of  a  chartered 
project  manager  and  project  management  techniques. 

In  recent  years,  the  project  management  concept  has 
been  applied  to  many  other  functions  where  there  is  a  spe- 
cific objective  which,  when  achieved,  means  the  end  of  the 
function.   Project  management  today  is  widely  used  in  in- 
dustry where  a  specific  product  must  be  developed  and  many 
functional  lines  must  be  crossed  in  its  development.   In- 
dustrial project  management  developed  along  the  same  lines 
as  the  Department  of  Defense  project  management.   Technological 
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advances  with  the  accompaning  need  to  concentrate  respon- 
sibilities for  development  and  production  effort  in  one 
organization  were  the  primary  factors  responsible  for  its 
adoption. 

The  application  of  project  management  techniques  to  the 
Naval  laboratory  is  a  direct  result  of  the  successes  achieved 
on  other  government  and  industrial  projects.   The  advantages 
of  project  management  techniques  for  equipment  development 
are  obvious  when  applied  to  organizations  where  the  emphasis 
is  on  projects  with  specific  objectives  and  well-defined 
points  of  completion  (as  in  the  Naval  laboratory  develop- 
ment project).   In  recent  years,  the  use  of  project  managers 
and  project  management  techniques  has  proven  to  be  an  ef- 
fective management  concept. 

C.   NELC  PROJECT  MANAGER  PROFILE 

The  laboratory  project  manager  is  a  key  individual  in 
a  process  which  is  meant  to  provide  for  more  economical  and 
effective  acquisition  of  equipment  having  the  required  per- 
formance and  operational  availability  which  can  be  sustained 
in  a  designated  military  environment.   As  a  key  individual 
in  the  development  project,  his  responsibilities  cover  many 
areas  and  he  should  have  a  versatile  background  in  adminis- 
trative areas  associated  with  engineering  as  well  as  in 
engineering  technology. 

From  the  interviews  and  research  conducted  at  NELC,  a 
"typical"  laboratory  project  manager  profile  can  be  developed, 
He  is  forty-five  years  of  age,  has  been  with  the  laboratory 
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for  eight  years,  has  a  degree  in  electrical  engineering  and 
has  had  experience  in  his  field  prior  to  coming  to  the  lab- 
oratory.  This  profile  does  not  fit  any  particular  individ- 
ual, but  is  an  aggregate  of  the  backgrounds  of  a  sample  of 
twelve  NELC  project  managers  (Figure  12) .   This  "typical" 
profile  reflects  the  Naval  Electronics  Laboratory  Center 
orientation  with  the  project  manager's  educational  back- 
ground in  electrical  engineering,  his  main  field  of  activity, 
In  addition,  from  the  twelve  profiles  available  to  the 
authors,  it  is  clear  that  a  basic  premise  of  Chapter  I  is 
supported  in  that  only  two  (E  and  K  in  Figure  12)  appear  to 
have  any  management  training  in  their  background.   Also, 
two  of  the  twelve  project  managers  in  the  sample  hold  ad- 
vanced technical  degrees. 

However,  any  specific  project  managers  background  will 
vary  and  his  opinions  as  to  what  is  most  important  in  his 
background  will  vary  greatly  from  project  manager  to  pro- 
ject manager,  depending  on  how  he  views  his  function.   One 
project  manager  interviewed  had  obtained  his  undergraduate 
degree  in  electrical  engineering/physics  and  his  masters 
degree  in  management.   He  considered  the  management  degree 
as  the  most  important  to  the  management  function  which  he 
performed.   In  other  words,  he  viewed  his  job  as  that  of  a 
manager  and  considered  the  management  education,  experience 
and  techniques  which  he  possessed  as  being  the  most  useful 
in  accomplishing  his  project  objectives.   On  the  other  hand, 
another  project  manager  with  a  degree  in  electrical  engineer- 
ing and  a  minor  in  business  administration  considered  the 
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PROJECT   MANAGER   PROFILES 
(Sample   of  12  NELC   P.M.'s) 


PROJECT 
MANAGER 

AGE 

EDUCATION 

WORK  EXPERIENCE 
LAST  TEN  YEARS 

YRS  AS 

P.M. 

YRS  AT 
NELC 

A 

'  46 

B.  S. 
ElctEng 

NOL  Corona 
NELC 

12.0 

3.2 

'j 

38 

M.  S. 

Computer 

NASA  &  NELC 

4.0 

5.8 

C 

41 

Physics 

Ryan  &  NELC 

4.0 

9.7 

=i      p 

49 

B.  S. 
ElctEng 

London 

NELC 

7.3 

-U.7 

50 


35 


B.    S. 

BusMgrat 


Navy  &  NELC 


7,* 


B.    S. 
ElctEng 


Aeronutronic 
NELC 


5.1 


7.4 


5.1 


» 

G 

38 

M.  S. 

T?  "»  — .  -I-T?  ^   „. 

Andrews  AFB 
NELC 

3.4 

3.4 

- 

H 

35 

B.  S. 
Math 

NELC 

4.0 

5.8 

-- 

-' 

I 

36 

B.  S. 
ElctEng 

Assoc. Aero  Sci. 
Labs  &  NELC 

4.0 

9.4 

"•= 

: 

J. 

31 

B.  S. 
ElctEng 

NSRF,  Guam 
NELC   • 

5.0 

13.0 

K 

44 

B.E./B.B.A. 
ElctEng 

NUWC,  TAA 
NELC 

5.9 

5.9 

- 

- 

L 

50 

H.  S. 

ElctEng 

NELC 

12.0 

22.8 

Figure  12 
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management  portion  of  his  education  as  unimportant.   He 
viewed  his  job  as  that  of  a  developmental  engineer.   He 
felt  he  hadn't  used  the  management  portion  of  his  education 
in  his  past  experience  and  most  of  the  formal  management 
procedures  learned  had  been  forgotten.   He  believed  that 
management  training  would  be  of  value  in  managing  his  pro- 
ject but  that  he  was  too  busy  dealing  with  pressing  prob- 
lems to  take  advantage  of  any  formal  management  training 
which  was  available. 

It  was  obvious  to  the  authors  that  the  manner  in  which 
the  two  project  managers  tracked  their  projects  reflected 
their  feelings  on  the  importance  of  a  management  orienta- 
tion.  There  seemed  to  be  organized,  orderly  procedures 
for  project  control  in  the  first,  while  the  second  was  a 
"put  out  the  fire"  approach.   However,  both  project  mana- 
gers were  managing  projects  which  appeared  to  be  successful 
in  that  they  were  making  progress  toward  the  development 
of  a  desired  system  and  kept  their  sponsor  well  enough 
satisfied  to  continue  supplying  funds.   In  addition,  both 
had  been  laboratory  project  managers  before  assignment  to 
their  current  projects.   This  tends  to  support  a  statement 
from  an  earlier  interview  that  a  NELC  project  manager  re- 
mains in  project  mangement  if  he  "gets  the  job  done." 

The  ability  to  do  whatever  is  necessary  to  "get  the 
job  done"  is  probably  the  single  most  important  trait  in  a 
project  managers  makeup.   He  must  be  able  to  make  decisions 
which  are  necessary  to  accomplish  project  objectives. 
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Formal  mangement  education  can  be  an  invaluable  part  of  the 
project  manager's  background  to  aid  him  in  making  the  right 
decisions,  but  is  not  essential.   Experience  gained  on  prior 
projects  or  assignments  and  individual  judgement,  common 
sense  and  an  intuitive  feel  for  making  the  right  decision 
can  enable  the  project  manager  to  successfully  control  his 
project.   The  ability  to  plan,  organize,  control  and  com- 
municate is  essential  to  getting  the  job  done  in  any  project 
and  every  project  manager  accomplishes  these  functions  one 
way  or  another,  with  or  without  formal  procedures.   He  may 
not  view  himself  as  a  manager  but  he  is  at  the  focal  point 
of  every  major  problem  area  of  his  .project.   His  ability  to 
handle  these  problems  (which  will  be  discussed  in  the  next 
section)  has  a  direct  bearing  on  whether  his  project  is 
successful,  partially  successful  or  cancelled.   The  problem 
areas  referred  to  are  management  problems  and  are  problems 
which  tend  to  recur  frequently.   There  is  no  intention  here 
to  imply  that  technical  problems  are  less  severe;  they  may 
in  fact  be  the  toughest  ones  to  solve,  but  they  are  general- 
ly unique.   The  recurring  problem  areas  are  management  prob- 
lems and  require  a  management  ability  (whether  formal 
education  or  experience  in  the  project  manager's  background) 
in  order  to  arrive  at  workable  solutions. 

D.   PLANNING,  CONTROLLING  AND  THE  SYSTEMS  APPROACH 

The  problem  area  concerned  with  planning  has  a  major  ef- 
fect on  management  problems  within  a  project.   Most  problems 
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which  develop  in  a  project  can  be  traced  to  poor  planning 
in  the  earlier  stages.   All  other  project  functions  depend 
on  planning,  deciding  what  to  do,  when  to  do  it  and  where 
to  do  it.   The  project  manager  must  plan  for  scheduling, 
budgeting,  contingencies,  personnel,  reports,  etc.  and  use 
the  systems  concept  of  planning  which  requires  looking  at 
the  organization  as  an  integration  of  all  of  its  parts. 
Many  problems  associated  with  project  management  can  be 
reduced  or  eliminated  with  good  planning  early  in  the  pro- 
ject's life. 

The  primary  results  of  faulty,  unrealistic  or  incom- 
plete planning  is  loss  of  control  over  many  aspects  of  the 
project  which  can  eventually  result  in  complete  loss  of  the 
project.   This  should  be  incentive  enough  for  any  project 
manager  to  do  his  utmost  to  ensure  that  adequate  planning 
for  his  project  is  accomplished.   This  planning  should  be- 
gin in  the  project  proposal  stage  with  the  sponsor's  task 
statement  and  continue  throughout  the  life  of  the  project. 
The  early  planning  should  include  project  organizational 
structure,  schedules,  manpower  requirements,  in-house  and 
contractor  efforts,  funding  requirements,  etc.   This  initial 
planning  effort  is  the  key  to  a  successful  project  with  a 
minimum  of  problems.   It  is  a  guideline  for  normal  project 
operations  and  is  a  baseline  to  fall  back  on  in  meeting 
unexpected  changes  and  crises. 

Planning  techniques  which  may  be  used  by  a  project  man- 
ager vary  in  complexity  and  usefulness,  depending  on  the 
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size  and  complexity  of  the  project.   A  small  single  func- 
tion project  may  require  a  relatively  simple  plan  and  plan- 
ning technique  while  a  large  complex  multifunction  project 
may  require  many  planning  techniques  and  documents  to  pro- 
vide adequate  direction.   However,  all  projects  should  have 
a  written  plan  covering  what  is  to  be  done,  how,  when,  by 
whom,  what  it  will  cost,  major  foreseeable  problems  and 
possible  solutions. 

A  detailed  explanation  of  planning  techniques  which  are 
useful  to  the  project  manager  is  beyond  the  scope  of  this 
paper.   Some  general  techniques  which  project  managers  have 
found  to  be  useful  in  project  planning  and  which  develop 
into  project  control  tools  as  the  project  progresses  include 

a  cumulative  expenditure  budget  which  plots  time 
versus  expenditures; 

a  rate  of  expenditures  budget  which  plots  time 
versus  expenditure  rate; 

bar  charts  with  project  milestones; 

networks  and  the  critical  path; 

work  breakdown  structures  which  can  set  the  stage 
for  all  subsequent  planning; 

make  or  buy  analysis;  and 

PERT,  which  is  an  excellent  planning  device  because 
it  details  the  sequence  of  steps  necessary  to  pro- 
ject completion  based  on  their  relation  to  each 
other . 


Some  illustrations  and  discussion  of  these  techniques  can 
be  seen  in  Appendix  A. 

Planning  is  one  of  the  initial  problems  the  project 
manager  must  face  and  it  is  not  an' easy  task.   However,  if 
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he  realizes  that  thorough,  complete,  well  thought  out  plans 
will  help  to  avoid  many  of  the  problems  which  may  develop 
in  the  future,  planning  should  become  easier.   The  project 
manager's  attitude  toward  planning  is  reflected  in  his  pro- 
ject organization  and  the  control  which  he  maintains  over 
his  project.   In  the  examples  of  two  project  managers  cited 
earlier,  one  viewed  his  job  as  that  of  a  manager  and  his 
management  orientation  was  reflected  in  thorough,  detailed 
project  planning,  while  the  other  viewed  his  job  as  that  of 
a  developmental  engineer  with  little  emphasis  on  management 
and  his  project  did  not  appear  to  contain  any  plan  to  assure 
that  the  project  progressed  toward  its  end  objectives.   For 
example,  the  second  project  was  in  the  advanced  development 
stage  and  there  was  no  plan  for  reliability  requirements, 
Quality  Assurance  or  Integrated  Logistic  Support  nor  were 
milestones  which  had  been  developed  in  planning  closely 
monitored.   In  fact,  the  project  manager  stated  that  mile- 
stone reports  (i.e.  keeping  track  of  milestones  made  and 
missed)  were  not  used,  were  not  helpful  in  project  control 
and  were  only  prepared  because  it  was  a  requirement.   Addi- 
tionally, there  appeared  to  be  no  real  control  system  used 
to  track  project  progress  (i.e.  PERT,  Gantt  charts,  mile- 
stones, graphs,  etc.).   There  seemed  to  be  a  general  feel- 
ing that  paperwork/reports  might  be  of  some  value  but  there 
wasn't  time  enough  to  prepare  and  use  them.   Lack  of  admin- 
istrative support  was  cited  as  one  reason  that  the  project 
appeared  to  be  a  generally  "off  the  cuff"  operation.   It 
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appeared  to  the  authors  that  with  some  additional  planning 
and  budget  control  the  project  might  find  funds  available 
to  hire  enough  administrative  support  to  allow  the  proper 
use  of  project  control  techniques.   For  example,  it  ap- 
peared that  the  only  fund  controlling  and  monitoring  tech- 
nique used  was  a  weekly  computer  printout  which  presented 
the  amount  each  functional  code  had  expended  on  the  project 
the  previous  week. 

In  contrast,  the  first  project  contained  detailed  net- 
works with  milestones  from  project  initiation  to  completion, 
all  responsible  personnel  were  identified,  there  was  a  com- 
prehensive Integrated  Logistic  Support  plan  and  Quality 
Assurance  plan  and  complete  budgeted  expenditures  were  laid 
out.   In  short,  where  the  project  was  ultimately  headed, 
where  it  had  been  and  where  it  would  be  at  any  point  in  the 
future  was  very  clear.   In  the  opinion  of  the  authors,  this 
type  of  detailed  planning  can  make  the  project  manager's 
job  much  easier,  solve  many  problems  as  they  arise  and 
give  the  project  a  much  greater  chance  for  success. 

Another  problem  area  for  the  project  manager  is  in  con- 
trolling his  project's  day  to  day  operations.   The  primary 
elements  concerned  with  project  control  are  budgets,  costs, 
schedules  and  progress.   If  a  project  manager  can  maintain 
control  of  these  four  elements  he  can  maintain  control  of 
his  project.   Costs  and  progress  refer  to  actual  costs  and 
progress  while  budgets  and  schedules  refer  to  planned  costs 
and  progress.   The  project  manager  must  be  able  to  track  actual 
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versus  planned  in  order  to  know  when  significant  deviations 
occur  and  take  action  to  correct  the  deficiency. 

Various  methods  were  used  by  laboratory  project  managers 
to  maintain  control  of  costs  and  progress.   One  of  the  bet- 
ter systems  was  based  on  the  use  of  milestones  and  mile- 
stone reports.   The  milestone  report  was  an  important  tool 
for  the  project  manager  in  controlling  his  project  and 
could  be  prepared  in  various  ways.   The  project  manager 
might  receive  an  input  from  each  responsible  task  leader, 
prepare  the  milestone  report  and  distribute  it.   Using  this 
method  does  not  necessarily  obtain  the  fullest  cooperation 
from  task  leaders  and  functional  managers  because  they 
might  interpret  the  report  as  only  reflecting  the  project 
manager's  viewpoint  and  biases  and  feel  that  the  milestone 
report  did  not  reflect  their  problems  or  the  real  reason 
a  milestone  was  missed. 

The  World  Wide  Military  Command  Control  System  Project 
Office  appeared  to  the  authors  to  have  an  excellent  method 
of  implementing  their  milestone  and  milestone  report  control 
system  which  encompassed  the  systems  concept  philosophy. 
The  WWMCCS  Project  Manager  felt  that  one  of  his  prime  func- 
tions was  to  obtain  the  cooperation,  understanding  and  full 
support  of  functional  personnel  for  his  project.   Therefore, 
he  prepared  a  detailed  milestone  report  on  a  weekly  basis 
which  was  a  function  of  a  Monday  milestone/project  review 
meeting.   This  meeting  was  attended  by  project  personnel 
and  all  functional  task  leaders  assigned  to  accomplish 
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project  tasks.   If  a  milestone  had  been  missed  in  the  pre- 
vious week  or  was  expected  to  be  missed  in  the  near  future, 
it  was  discussed  with  the  responsible  task  leader,  the  re- 
port was  prepared  and  was  eventually  reviewed  at  the  depart- 
ment head  level.   Since  one  of  the  prime  objectives  of  the 
project  manager  was  to  obtain  and  present  a  clear  and  total 
picture  of  his  project's  progress  and  schedule,  the  con- 
tents of  every  milestone  report  was  prepared  with  the  co- 
operation and  agreement  of  the  responsible  task  leader  and 
his  input  was  the  most  important  part  of  the  report. 

In  addition  to  milestones,  the  WWMCCS  Project  Office 
prepared  a  monthly  management  control  document  for  use  as  a 
project  control  tool.   Again,  the  most  important  input  came 
from  the  functional  departments  and  gave  the  project  manager 
a  more  accurate  overall  view  and  better  understanding  of  his 
project  and  the  organization.   This  document  contained  net- 
works with  milestones  for  each  task  leader,  cumulative  mile- 
stones met  and  missed  to  date  with  an  explanation  of  any 
missed  and  a  plot  of  budgeted  versus  actual  costs  to  date. 
The  explanation  of  missed  milestones  included  an  estimate 
of  its  probable  effect  on  the  project  as  a  whole  and  a  new 
expected  completion  date  for  the  milestone. 

Another  weekly  meeting  was  used  for  the  project  configu- 
ration management  program  and  included  a  review  of  detailed 
engineering  change  requests,  engineering  change  orders  and 
field  engineering  change  reports.   The  day  to  day  tools 
used  by  the  project  manager  to  control  his  project  included 
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graphs,  Gantt  charts  and  networks.   An  example  is  the  fi- 
nancial status  chart  which  is  strictly  a  project  manager's 
tool  and  tracks  budgeted  versus  actual  expenditures  (Ap- 
pendix A  contains  examples  of  project  control  tools,  some 
of  which  were  used  in  the  WWMCCS  Project  Office). 

There  was  also  frequent  contact  with  task  leaders,  con- 
tractors and  the  sponsor  through  telephone  calls  and  meet- 
ings.  The  project  manager  felt  that  the  management  tools 
which  he  used  were  essential  if  he  was  to  maintain  adequate 
control  of  his  project  and  a  clear  understanding  of  the 
problems  and  relationships  which  affected  it  throughout  the 
organization. 

Whatever  management  control  techniques  the  project  man- 
ager uses,  they  must  tell  him  what  progress  (in  both  sched- 
ule and  performance)  he  is  getting  for  the  money  he  is 
expending,  give  him  enough  detail  on  trouble  areas  so  that 
he  can  take  the  required  action,  and  enable  him  to  see  up- 
coming problems.   To  know  where,  when,  why  and  what  kind  of 
action  to  take,  the  project  manager  must  be  able  to  track 
his  project  cost,  schedule  and  performance.   He  must  simul- 
taneously consider  all  these  elements  of  his  project  and 
their  effect  on  each  other.   How  well  he  does  this  deter- 
mines the  effectiveness  of  his  management  —  whether  he  will 
control  the  project  or  be  controlled  by  the  project. 

A  major  problem  area  which  created  much  concern  within 
every  project  office  and  for  each  project  manager  inter- 
viewed was  budget  cuts.   The  project  manager  has  little 
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control  of  budget  cuts  from  his  project  sponsor  and  there 
seems  to  be  no  optimum  way  to  plan  for  or  predict  cuts  in 
total  funds.   Planning  for  contingencies  can  include  a  plan 
for  certain  cuts  in  particular  areas  to  aid  in  the  accom- 
panying reduction  of  effort,  and  the  project  manager  should 
have  priorities  set  up  from  the  most  to  least  critical 
areas  in  his  project.   When  a  budget  cut  comes  from  the 
sponsor,  there  are  basically  three  methods  a  project  man- 
ager can  use  to  reduce  the  funds  to  the  functional  depart- 
ments.  He  can  eliminate  the  lowest  priority  tasks  if  he 
has  planned  with  priorities  in  mind  and  the  nature  of  his 
project  allows  it.   He  can  reduce  the  level  of  effort  on 
each  task  by  a  set  percentage  and  settle  for  reduced  per- 
formance and  a  less  desirable  schedule.   Finally,  he  can 
try  to  reduce  the  funds  to  the  functional  departments  so  as 
to  have  the  least  impact  on  his  project  while  at  the  same 
time  considering  the  current  situation  in  each  functional 
department  (manpower  utilization,  current  need  for  funds, 
etc.)  and  make  cuts  that  have  the  least  effect  on  the  en- 
tire organization.   Again,  to  do  this  he  must  have  planned 
with  priorities  in  mind  so  he  knows  where  he  can  accept 
less  performance. 

As  indicated  in  Chapter  II,  the  authors  consider  the 
systems  approach  as  primarily  a  management  philosophy  or 
way  of  thinking  which  a  project  manager  can  use  as  a  frame- 
work to  visualize  the  system  in  which  he  operates  and  how 
his  project  or  area  of  responsibility  is  constrained  and 
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influenced.   The  systems  concept  can  make  the  job  of  man- 
aging a  project  easier  by  giving  a  better  understanding  of 
the  system,  but  it  can  also  make  some  decisions  more  dif- 
ficult be  requiring  the  consideration  of  more  variables 
(e.g.  the  decision  to  use  in-house  effort  rather  than  an 
outside  contract  for  the  development  of  a  particular  module 
might  be  easily  made  if  the  only  variable  considered  is 
initial  cost )  . 

The  systems  approach  can  be  applied  when  considering 
the  method  used  by  a  project  manager  in  distributing  funds. 
If  the  project  manager  is  always  thinking  of  his  project 
alone  and  always  makes  decisions  in  the  light  of  their  im- 
mediate effect  on  his  project,  he  may  attempt  to  use  com- 
mercial contractors  to  a  maximum  extent  in  order  to  obligate 
as  much  of  his  budget  as  possible  to  guard  against  budget 
cuts  (i.e.  funds  within  the  laboratory  are  easily  recalled 
by  a  sponsor  while  funds  obligated  in  a  contract  are  not). 
This  method  of  handling  funds  may  reduce  the  difficulty  of 
a  future  project  decision  when  a  budget  cut  comes,  but  it 
may  also  cause  problems  in  the  overall  system.   The  func- 
tional departments  are  partially  dependent  on  the  Command 
Control  and  Communications  Programs  Department  as  a  source 
of  funds.   If  the  functional  departments  are  not  utilized 
whenever  possible  by  project  managers,  in  the  long-run  the 
total  system  may  suffer. 

Most  successful  project  managers  employ  the  systems  ap- 
proach to  project  management  whether  they  realize  it  or  not. 
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In  the  example  on  budget  cuts,  one  project  manager  inter- 
viewed used  the  systems  approach  in  the  decision-making 
process  concerning  redistribution  of  funds  to  the  function- 
al areas  involved  in  his  project.   After  receiving  a  budget 
cut  from  his  sponsor,  the  project  manager  would  first  look 
at  areas  which  were  least  critical  to  the  project  as  pri- 
mary candidates  for  the  major  portion  of  the  fund  reduction, 
At  the  same  time  however,  he  would  look  at  the  present  and 
possible  future  situation  in  the  particular  functional  de- 
partments concerned.   Factors  such  as  the  workload  in  the 
department,  its  present  need  for  funds  and  its  ability  to 
transfer  personnel  to  other  projects  might  be  considered  or 
might  be  factors  which  eventually  tip  the  scales  in  favor 
of  a  greater  fund  reduction  in  one  functional  area  versus 
another. 

A  project  manager  must  know  the  organization  in  which 
he  operates.   He  should  know  how  each  subsystem  within  the 
total  system  functions  and  their  relationship  to  each  other 
in  order  to  understand  the  overall  effects  his  decisions 
will  have.   An  example  of  using  the  systems  approach  or  con- 
sidering other  subsystems  in  the  organization  when  making 
project  decisions  is  in  the  area  of  contracting.   The  labo- 
ratory project  manager  must  understand  the  procurement  pro- 
cess and  exactly  what  is  involved  in  government  contracting 
with  commercial  sources .   The  Supply  and  Contract  Services 
Division  within  the  Administrative  and  Technical  Support 
Department  performs  a  very  important  function  for  the  pro- 
ject manager  when  he  must  utilize  a  commercial  contractor 
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to  perform  a  certain  task  or  level  of  effort.   The  contract 
specialists  are  in  the  organization  to  facilitate  the  NELC 
procurement  cycle  (Figure  11)  and  act  as  an  interface  between 
the  project  manager  and  the  Navy  Regional  Procurement  Office 
(NRP9).   A  primary  part  of  the  procurement  cycle  and  one 
which  must  be  understood  by  the  project  manager  is  the  pro- 
curement leadtime  (Figure  13).   If  the  project  manager  is 
aware  of  the  procurement  requirements  and  procedures  which 
must  be  accomplished  prior  to  contract  award,  makes  an  at- 
tempt to  bring  the  contracting  specialists  into  the  prepara- 
tion of  the  procurement  package  as  early  as  possible  and 
understands  the  constraints  which  face  anyone  involved  in 
government  procurement,  he  will  not  only  be  increasing  the 
probability  of  having  a  successful  project  but  will  be 
helping  the  total  system  to  meet  its  objectives. 

A  project  manager  cannot  sit  in  his  office,  make  his 
plans  and  control  his  project  without  understanding  the 
requirements  of  other  subsystems.   For  example,  a  project 
manager  may  have  planned  for  many  months  to  procure  a 
particular  piece  of  equipment  which  he  needs  on  a  certain 
date  to  meet  his  schedule.   Without  really  understanding 
the  leadtime  involved  in  the  procurement,  he  prepares  the 
procurement  package  and  it  arrives  on  the  contract  special- 
ist's desk  with  a  notation  to  the  effect  that  the  item 
"must  be  in  the  project  office  within  thirty  days  or  the 
schedule  is  shot."   If  the  procurement  requires  competition 
according  to  the  Armed  Services  Procurement  Regulations, 
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The  following  indicates  average  number  of  days  elapsed 
between  the  time  the  purchasing  office  receives  a  complete 
procurement  package  to  contract  award. 

Calendar  days 

a.  Requirements  to  be  negotiated  with       210 
an  estimated  cost  in  excess  of 
$2,000,000 

b.  Requirements  to  be  negotiated  with       160 
an  estimated  cost  between  $300,000 

and  $2,000,000 

c.  Requirements  to  be  negotiated  with       1*13 
an  estimated  cost  between  $100,000 

and  $300,000 

d.  Requirements  to  be  negotiated  with        91 
an  estimated  cost  between  $10,000 

and  $100,000 

e.  Requirements  to  be  formally  adver-       120 
tised  in  excess  of  $10,000 

f.  All  other  requirements,  exclusive         60 
of  Installment  Funding 

g.  Amendments  involving  exclusively  20 
the  addition  of  funds  in  accordance 

with  an  existing  Installment  Funding 
Clause 


Figure  13.   Procurement  Leadtimes 
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the  leadtime  required  just  to  get  the  contract  signed  may 
be  ninety  days  or  more.   If  the  need  is  urgent  enough  and 
another  procurement  method  can  be  justified,  the  contract- 
ing division  may  be  able,  through  extra  effort  and  some 
kind  of  "firedrill,"  to  reduce  the  leadtime  and  meet  the 
project's  schedule.   If  the  project  manager  had  understood 
the  effort  involved,  he  may  have  brought  the  contracting 
specialist  in  much  earlier  and  been  able  to  prevent  many 
headaches  for  himself  and  others.   Looking  at  his  organiza- 
tion as  a  system  made  up  of  subsystems  which  affect  each 
other,  the  project  manager  can  reduce  many  of  his  problems 
and  total  system  problems. 

A  final  example  of  the  systems  approach  in  laboratory 
project  management  is  in  the  area  of  personnel.   A  project 
manager  normally  has  little  real  influence  on  the  selection 
of  which  individuals  will  be  assigned  to  his  project  from 
the  functional  departments,  but  can  sometimes  "politic"  to 
influence  the  assignment  of  a  certain  key  individual  when 
he  has  strong  feelings  that  the  individual  and  task  are  well 
matched.   This  procedure  can  be  beneficial  to  both  the  pro- 
ject and  the  organization  as  a  whole  if  not  carried  to  an 
extreme.   If  a  particular  project  manager,  because  of  his 
project's  priority  or  his  persuasive  ability,  is  able  to 
obtain  the  best  qualified  people  from  each  functional  de- 
partment with  which  he  deals,  his  project  will  be  well 
staffed  with  the  best  talent  but  other  projects  and  overall 
organizational  effectiveness  will  suffer.   To  use  the  systems 
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approach,  the  project  manager  must  view  manpower  management 
as  a  subsystem  interacting  with  other  subsystems  in  the  or- 
ganization.  He  should  develop  a  personnel  program  that  is 
adaptable  to  his  project  and  can  be  directed  toward  estab- 
lishing and  maintaining  an  adequate  and  satisfactory  pro- 
ject team.   He  must  strive  to  staff  his  project  with 
personnel  who  are  compatible  with  the  objectives  of  his  pro- 
ject, not  necessarily  the  individuals  who  appear  best 
qualified  in  every  technical  area. 

To  use  the  systems  approach  is  not  difficult  but  it 
requires  the  ability  to  see  beyond  the  immediate  effects 
and  advantages  of  a  given  decision.   It  requires  the  ability 
to  see  the  "big  picture"  or  what  is  best  for  the  total  sys- 
tem in  the  longrun.   It  may  even  require  a  project  manager 
to  say  "this  project  is  not  going  anywhere,  it's  a  waste 
of  money  and  should  be  discontinued"  with  the  full  know- 
ledge that  if  it  is  dropped,  he  must  find  a  new  project  and 
source  of  funds. 
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V.   CONCLUSIONS 

The  systems  approach  to  management  is  a  way  for  the 
manager  to  view  his  environment  which  allows  him  to  make 
more  viable  decisions.   If  the  laboratory  project  and 
project  manager  functioned  in  a  vacuum;  if  every  decision 
affected  only  the  project;  then  the  systems  approach  would 
not  apply  to  NELC .   However,  from  the  very  nature  of  the 
laboratory  organizational  structure  and  from  the  manner  in 
which  it  operates  (as  described  in  Chapters  III  and  IV),  it 
is  apparent  to  the  authors  that  the  systems  approach  is  the 
most  applicable  management  concept  for  NELC. 

The  systems  approach  has  been  applied  by  some  project 
managers  (although  they  may  not  have  called  it  the  systems 
approach)  with  success.   Other  management  approaches  may  be 
more  successful  in  some  situations  over  the  short-term,  but 
the  systems  approach  should  provide  the  most  rewarding  long- 
term  benefits  for  the  laboratory  project  manager. 

The  NELC  project  manager  is  normally  an  engineer  or  an 
individual  with  a  technical  background.   This  technical 
training  is  of  prime  importance  to  the  project  manager  and 
helps  him  to  deal  with  the  difficult,  complicated  and  some- 
times unsolvable  technical  problems  which  are  encountered 
in  a  development  project.   However,  when  a  developmental 
engineer  moves  from  the  laboratory  bench  to  the  project 
manager's  desk,  the  recurring  problems  which  he  must  face 
are  management  problems.   Budgeting,  re-budgeting  and 
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tracking  expenditures  for  example,  are  day  to  day  problems 
which  are  encountered.   Failure  to  effectively  plan  for  and 
control  these  types  of  problems  can  lead  to  the  failure  of 
a  project  just  as  surely  as  the  inability  to  solve  a  major 
technical  problem  can  be  a  project's  downfall. 

Therefore,  the  laboratory  project  manager  must  realize 
that  he  is  more  than  an  engineer.   He  is  also  a  manager  and 
he  must  develop  a  management  philosophy  which  will  enable 
him  to  cope  with  the  management  problems  he  faces.   The 
management  tasks  should  not  be  underestimated.   Careful 
attention  should  be  paid  to  the  planning  process,  including 
the  identification  and  analysis  of  alternatives,  and  a  clear 
cut  understanding  of  the  actions  and  responsibilities  of 
supporting  personnel  both  within  and  outside  the  Naval 
laboratory.   In  addition,  the  project  manager  must  have  an 
effective  control  system  that  provides  timely  feedback  on 
potential  problems  and  allows  him  to  take  corrective  action. 
He  must  have  a  management  orientation  or  philosophy  which 
allows  him  to  see  the  entire  project  and  all  of  its 
interfaces . 

In  interviews  conducted  over  the  six  month  period,  there 
appeared  to  the  authors  to  be  no  universal  understanding  or 
use  of  the  systems  approach.   However,  it  was  obvious  that 
some  project  managers  operated  under  the  systems  philosophy 
and  thought  positively  in  a  managerial  sense  and  that  to 
some  extent  the  systems  approach  was  used  by  everyone  inter- 
viewed.  In  other  words,  for  a  project  manager  to  successfully 
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function  in  an  environment  such  as  NELC  where  frequent  contact 
is  required  with  subsystems  other  than  his  own,  he  must  be 
able  to  understand  and  obtain  the  cooperation  of  these  sub- 
systems.  Otherwise  he  will  not  be  likely  to  remain  a  pro- 
ject manager.   Nevertheless,  in  the  opinion  of  the  authors 
he  can  be  a  more  effective  project  manager  if  he  is  aware 
of  the  systems  concept  and  attempts  to  make  every  decision  - 
in  the  light  of  its  affect  on  other  subsystems  and  the  total 
system. 

The  NELC  project  manager  appeared  to  operate  under  some 
constraints  which  may  not  be  common  to  project  managers  in 
general.   Within  his  organization  he  operated  as  an  indi- 
vidual in  a  chain  of  command  with  a  supervisor  directly 
above  who  placed  demands  upon  him.   Ke  also  had  to  satisfy 
his  project  sponsor  who  was  external  to  the  organization. 
The  fact  that  he  was  trying  to  satisfy  two  bosses  whose  ob- 
jectives might  not  coincide  is  in  conflict  with  basic  prin- 
ciples of  any  management  approach.  'An  example  was  the 
individual  who  let  internal  requirements  slide  so  he  would 
have  time  available  to  satisfy  sponsor  requirements.   In 
his  mind,  and  maybe  rightly  so,  he  could  not  justify  the 
time  required  to  deal  with  all  internal  demands.   This  type 
of  situation  will  make  it  more  difficult  for  the  individual 
manager  to  practice  the  systems  approach  (i.e.  when  the  de- 
mands of  one  interface  are  seen  as  all  important,  the  re- 
lationship with  others  is  degraded). 
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Another  constraint  with  which  the  NELC  project  manager 
must  deal  is  in  the  area  of  commercial  contracts.   The  pro- 
ject manager  in  industry  normally  has  complete  control  of 
his  project  and  can  subcontract' tasks  when  necessary.   The 
laboratory  project  manager  on  the  other  hand,  has  no  con- 
tracting authority.   In  fact,  to  contract  with  a  commercial 
vendor  he  must  go  through  two  more  systems  or  organizations. 
First 3  he  deals  directly  with  contracting  specialists  in 
the  Supply  and  Contract  Services  Division  to  prepare  his 
procurement  package.   Then  the  Supply  and  Contract  Services 
Division  must  interface  with  the  Navy  Regional  Procurement 
Office  which  lets  the  contract.   From  the  viewpoint  of  the 
project  manager  this  is  not  an  ideal  contracting  procedure, 
but  it  illustrates  the  necessity  for  the  project  manager  to 
understand  systems  other  than  his  own,  know  their  constraints 
and  procedures  and  made  decisions  which  affect  his  project 
with  the  knowledge  of  their  affect  on  those  systems . 

In  preparation  of  the  procurement  package  and  specifica- 
tion writing,  there  appears  to  be  a  need  for  more  coopera- 
tion and  understanding  between  laboratory  project  managers 
and  contracting  personnel.   At  NELC,  various  methods  could 
be  used  to  promote  a  more  effective  interface  between  the 
contracting  specialist  and  the  project  office.   One  method 
would  be  to  divide  the  projects  among  the  contracting  spe- 
cialists so  that  the  individual  specialist  could  more  closely 
relate  to  specific  projects,  maintain  close  contact  with  his 
specific  project  managers  and  be  better  able  to  see  progress 

and  anticipate  project  needs. 
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At  the  same  time,  every  project  manager  should  take 
advantage  of  opportunities  to  increase  his  knowledge  of 
procurement  procedures  and  internal/external  requirements 
placed  on  the  Supply  and  Contract  Services  Division.   For 
example,  in  December  1973  a  short  three  day  research  and 
development  procurement  course  was  offered  at  NELC  which 
presented  an  ideal  opportunity  for  project  management  types 
to  increase  their  understanding  of  the  procurement  process. 
Only  two  of  the  eighteen  NELC  personnel  who  attended  the 
course  were  directly  related  to  project  management.   The 
majority  of  the  class  consisted  of  contracting/supply  per- 
sonnel and  the  subject  covered  was  basically  a  review  for 
them.   This  type  of  course  could  be  most  beneficial  to  the 
typical  project  manager  in  furthering  his  knowledge  of  pro- 
curement procedures  and  improving  his  interface  with  con- 
tracting specialists. 

Project  management  personnel  should  also  take  advantage 
of  management  training  opportunities  whenever  possible  and 
higher  level  management  should  see  that  these  opportunities 
are  made  available.   Any  training  course  which  is  offered 
should  be  well  advertised  throughout  the  organization  and 
its  intended  purpose  should  be  specified  (i.e.  procurement 
orientation  for  project  management  personnel,  specific  man- 
agement training,  etc.).   The  opinion  was  expressed  that 
some  type  of  management  training  would  be  nice  but,  as  a 
project  manager,  there  was  not  time  to  attend  courses,  etc. 
Be  that  as  it  may,  the  authors  feel,  that  if  a  project  manager 
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would  take  the  time  to  acquire  a  few  good  management  tools 
through  training,  the  "fires"  which  require  immediate  and 
constant  attention  would  be  much  less  common  and  time 
consuming. 

A  prime  consideration  in  enabling  laboratory  project 
managers  to  understand  and  use  the  systems  approach  is  in 
the  attitude  of  higher  level  management .   If  senior  man- 
agers realize  that  the  transition  from  developmental 
engineer  to  project  manager  is  not  always  an  easy  one  and 
that  some  individuals  should  have  a  mangement  orientation 
or  training  to  more  successfully  meet  organizational  and 
project  objectives,  then  management  training  will  be  made 
available  and  project  managers  and  prospective  project  man- 
agers will  be  strongly  encouraged  to  take  advantage  of  it. 

Finally,  in  the  opinion  of  the  authors,  the  matrix 
organization  as  utilized  at  NELC  is  an  effective  and  flexi- 
ble structure,  well  suited  to  meet  both  project  and  func- 
tional goals.   With  its  many  interfaces  and  subsystems  it 
is  the  ideal  structure  in  which  a  project  manager  can 
practice  the  systems  approach  to  management.   The  project 
manager  may  "get  by"  with  no  management  philosophy  or  the 
philosophy  that  what's  good  for  his  project  is  good  for  the 
total  system.   However,  the  authors  believe  that  if  a  pro- 
ject manager  will  consciously  practice  the  systems  approach 
to  management  his  job  will  be  easier,  his  project  will  have 
a  better  chance  for  success,  other  subsystems'  goals  will 
be  more  easily  met  and  the  total  system  will  benefit. 
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APPENDIX  A:   SOME  ILLUSTRATIONS  AND  DISCUSSION  OF  PLANNING 
AND  CONTROL  TOOLS 


The  following  pages  contain  some  general  examples  of 
planning  and  control  tools  and  techniques  which  can  be  use- 
ful in  managing  a  project,  along  with  some  specific  examples 
of  tools  used  by  a  laboratory  project  manager  to  plan  for 
and  control  his  project.   Some  examples  are  very  simple 
and  their  purpose  is  one  of  illustration.   However,  some 
project  managers  could  probably  increase  the  value  of  their 
planning  and  control  by  thinking  about  how  they  might  ap- 
ply something  as  simple  as  a  plot  of  planned  versus  actual 
expenditures  to  their  project. 

At  the  end  of  this  appendix  there  is  a  brief  discussion 
of  PERT  which  is  intended  as  a  familiarization.   An  il- 
lustration of  PERT  is  beyond  the  scope  of  this  paper  but 
a  detailed  explanation  can  be  obtained  from  many  sources, 
one  of  which  is  MIL-P-23189A  (Navy)  'dated  25  October  1962, 
a  milspec  on  PERT/Time  and  PERT/Cost  Management. 
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TRACKING  EXPENDITURES  VERSUS  BUDGET 

It  is  not  controlling  to  track  cumulative  expenditures 
as  in  the  upper  chart.   Expenditures  must  be  compared  with 
planned  expenditures  (budget)  as  in  the  lower  chart  in  order 
that  deviations  may  be  detected  and  corrective  action  taken. 
The  upper  chart  gives  a  manager  very  little  useful  informa- 
tion.  The  lower  chart,  however ,    clearly  points  out  that 
more  money  than  planned  is  being  spent  and  that  something 
had  better  be  done  soon  to  correct  the  trend. 
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The  chart  depicted  below  is  an  illustration  of  a  chart 
used  to  track  expenditures  with  funds  budgeted  (in  this 
case  budgeted  means  funds  set  aside  for  the  project's  use), 
funds  actually  expended  and  planned  expenditures  all  shown. 
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BAR  CHARTS 


Bar  charts  are  another  tool  which  can  be  used  to  track 
progress  and  may  be  as  simple  or  as  detailed  as  desired. 
However,  as  can  be  seen  from  the  two  charts  below,  an  indi- 
cation- of  tasks  completed  (upper  chart)  is  almost  meaning- 
less Compared  to  progress  versus  schedule  (lower  chart) . 
The  lower  chart  clearly  points  out  that  tasks  1  and  3  are 
behind  schedule  while  2  is  complete  and  4  has  been  completed 
well  ahead  of  schedule. 
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NETWORK  AND  MILESTONE  CHARTS 

The  following  four  pages  are  examples  of  typical  mile- 
stone charts  used  by  the  WWMCCS  Project  Office  primarily 
for  planning  purposes.   The  milestone  charts  are  made  up 
by  the  task  leaders  and  submitted  to  the  project  manager 
for  approval.   Milestone  charts  are  excellent  tools  to  aid 
in  the  planning  process  but  are  also  used  to  track  the 
project. 

It  is  not  intended  that  the  reader  interpret  the 
figures j  symbols,  etc.  on  the  charts,  they  are  simply  ex- 
amples of  control  tools  in  use  by  a  particular  project. 
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MILESTONE  REPORTS        .  . 

An  example  of  a  typical  milestone  report  is  contained 
in  the  following  seventeen  pages.   This  particular  mile- 
stone report  was  prepared  by  the  WWMCCS  Project  Office 
to  cover  the  week  ending  7  December  1973.   The  milestone 
report  is  an  excellent  control  tool  in  that  it  gives  an 
overview  of  the  entire  project  (excluding  funds)  and  al- 
lows the  manager  to  see  progress  made  and  expected  to  be 
made  in  the  future . 

It  should  be  noted  that  milestones  are  explained  and 
discussed  in  the  report  along  with  their  probable  impact 
on  the  project.   The  fact  that  a  milestone  was  missed  may 
or  may  not  be  significant,  depending  upon  its  relationship 
to  other  milestones  and  the  project  as  a  whole. 
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LFC  Prog  Maintenance  Manuals  D 


5320 


10/29 

11/12 

11/12 

11/19 

11/19 

11/30 

12/7 

12/10 

12/14 

12/14 

12/17 

1/4 

1/11 

1/14 

1/14 

1/18 

2/8 

2/15 


=    Start 
=    Finish 


P 

D 


=    Preliminary 
=    Deliverable 


E    =     External  Deliverable 
*     =     Completed  early 


10/29 
11/12 

11/12 
11/19 
11/19 
*ll/28 
11/30 


CHECK  ONE 


Q 


X 

X 

X 
X 
X 
X 
X 


MISSED 


-'   7. 

-   C  -i  ■ 


R£  I  2 
-  ■  <■>  •  ~ 
ecu       o 


TOTALS 


7      0    i    0    .    o 


SMILESTONES  MISSED   (INCLUDE  REASONS,  EFFECT  ON  PROBLEM/PROJECT,  REMEDIAL  ACTION 
TAKEN,  AND  WHEN) 
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'Mum:' 


.v*-*j  cjl 


■  •.  t.  .  —  - 


DATE 


-tr»i»'«i«rriiwri»  <>».».'         r     . 


10  D    ■    ber  19/3 

1 1  i.i i  ::ci  c»t  3i       i    3   ■     ■ .  < 


ONE  REPORT 'DETAIL 

PROBLEM  MANAGER,  CODE  ]  ]  30 

PROGRAM  MANAGER,  CODE        1100 


PROBL£M/fl?OJECT 

N424/0SIS 


WEEK  ENDING 

7  December  1973 


MILESTONE 


Z  b) 


u 


l.'o. 

701 
702 
703 
704 
705 


IDENTIFICATION 


Command  Manual  (2.0)  S 

Program  Maintenance  Manual  (1.7)  D 

Program  Maintenance  Manual  (2.0)  S 

Command  Manual  (2.0)  D 

Program  Maintenance  Manual  (2.0)  D 


Previous  FY-74  Milestones  completed 


O  -J 

d    — 


a  2  o 


5320 


MILESTONE  DATE 


SCHEDULKD 


RCVI5ED 


7/2 

7/13 

7/16 

11/16 

12/14 


CHECK   ON' 


ACTUAL 

7/2 
*7/12 

7/16 
11/19 


X 

X 

X 
X 


c  " 


~    i  -. 
,5,  ,LI- 


ID: 


s 

F 


Start 
Finish 


p   n    Preliminary 

D   =     Dsliverabls 


E   »    External  Deliverable 
*    =    Completed  early 


(MILESTONES  feilSSED   (INCLUDE  REA'CNS,  Li-FECT  Oil  f  ROCiLEM/VROJECT,  l\EMEOIAL  ACTION 
TAKEN,  AMD  WHEN) 


FY-74 
TOTALS 
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i\ 


Chm-l  REV  C 


■ 


'■»iu:<l 


'■',-r-v  '.^.UaaJvI     V..\.  Y.C.l-K  '>,-'- '—■•.... 


ONE  REPORT*  DETAIL 

PROBLEM  MANAGER,  CODE  1130 

PROGRAM  MANAGER,  CODE        H  00 


PROBLLM/PROJECT 

m 24 /OS  IS 


WEEK  ENDING 


101 
102 
103 
104 


sD: 


ILESTONE 


IDENTIFICATION 


Z  u  u 

°-  a  n 

O  —  U 

u  ^  o 


Phase  2.0  Training  Plan 

Phase  2.0  Lesson  Plans/Trng  Aids 

Phase  2.0  Training  Plan 

Phase  2.0  Lesson  Plans/Trng  Aids 


V  v" 


Previous  FY-74  Milestones  completed 


>320 


7  Decerrber  1973 


MILESTONE  DATE 


SCHEDULED 


7/4 

9/4 

9/14 

11/16 


HF.VISEO 


9/28 
12/7  " 


ACTUAL. 

7/4 
9/4 
9/28 
12/7 


S    ■    Start 
F    =     Finish 


P    »    Preliminary 
D   E     Celiverabla 


E    "    External  Deliverable 
*    =    Completed  early 


IMIUiSTONdS  MISSED   {lUCLUCii  n^AWW,  CrpCCT  O.N  f-rJOCSLCM/^noJ^CT,  F<EMCDIAL  ACTION 
TAKEN,  t.UO  WHEN) 


1  milestones  on  this  page  have  been  completed, 


TOTALS 


CHECK   ON! 


Id 
Q 
< 


15      1 


X 
X 


3— 


FY-74      19       3 
TOTALS 


r\ 
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— !^r-.; — i  ■ — -irr-^za^Lnu^eTtarri^LJLC^umi.  |Jrxaa>nrac3>^i  I  mnavaa-Mj  roreKa£«-n--2,-  ekk  _t.ti  jawia>  SOS r.ssaauncnr  -ii 


/  (     M 


DAI ; 


1 0   P    "      !     r    | 


r.r.r^rtTi. .  .'r,wunu<.n':iu 


ONE  R-EPORT-  DETAIL 

PROBLEM  MANAGER,  CODE 
PROGRAM  MANAGER,  CODE 


1130 
1100 


PROBLEM/PROJECT 

N424/0SIS 


MILESTONE 


No. 


201 
208 
209 
212 
213 
214 
204 
205 
210 
211 
'15 
16 


MB 

km 

:19B 
203 
21B 
22B 
23B 
24  B 
25B 
26B 
27B 


IDENTIFICATION 


ELINT  Funct  Descrip  "(Prelim) 

Conversion  Status  Report 

EGC-10  Coding 

Conversion  Status  Report 

EGC-10  Coding 

Geo-Correlation  Unit  Checkout 

ELINT  Funct  Descrip  (Prelim) 

Design  Review  (ELINT) 

Design  Review  (ELINT) 

ELINT  Funct  Descrip  (Final) 
ELINT  Funct  Descrip  (Final) 
Geo-Correlation  Unit  Checkout 


ELINT  SSD  (Sects  1-3) 

ELINT  Data  Reouirements 

ELINT  SSD  (Sects  1-3) 

ELINT  SSD  (Prelim) 

ELINT  SSD  (Prelim) 

ELINT  Data  Requirements 

ELINT  Design  Review 

ELINT  Dssion  Review 

ELINT  SSD'=(Final) 

ELINT  SSD  (Final) 

ELINT  Data  Requirements  (Final) 


S 
S 

s 

F 
F 
S 
D 
S 
F 
S 

D 
F 


S 

s 

F 
S 
P 
P 

s. 

F 
S 

D 

D 


Z  W  hi 


WEEK  ENDING 


7  December  1973. 


MILESTONE  DATE 


iSCHEDULED,      REVISED 
'  I 


5320 


Previous  FY-74  Milestones  completed 


8/6 
9/10 
9/10 
10/19 
10/19 
10/22 
11/2 
11/7 
11/8 
11/12 

11/23 
11/30 


12/3 
12/3 

1/11 

1/14 

2/15 

2/15 

2/19 

3/1 

3/4 

3/15 

3/15 


CHECK  ONE 


|      U 

i  3 

ACTUAL  < 


12/7 

12/7 


8/6 
9/10 
9/10 
*10/16 
*10/16 
10/22 
10/29 
11/7 
J.T/8 
11/12 
12/6 


12/3 


X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 


MISSED 


C£U 


o 


u     a 

z  *  — 


D  -' 


): 


S    =    Start 
F    =     Finish 


P    =    Preliminary 
D   =    Deliverable 


E    -     External  Deliverable 
*    =     Completed  early 


TOTALS 


12 


MILESTONES  MISSED    (INCLUDE  REASONS,  EFFECT  ON  PROBLEM/PROJECT.  REMEDIAL  ACTION 
TAKEN,  AND  WHEN) 


FY-74 
TOTALS 


12 


No .  216  -  This  milestone  was  missed  due  to  delay  in  receipt  of  mail.  Estimated 

completion  date  is  14  December  1973.  No  impact  on  the  program  is 

anticipated.  Responsible  code  is  Code  1130. 
No.  218B  -  This  milestone  was  missed  due  to  key  person  being  on  leave.  Estimated 

start  date  is  10  December  1973.  No  impact  on  the  program  is  anticipated, 

Responsible  code  is  Code  5320. 
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1URC 


Chart  REV  B 

DAI  i 

in  Do  i  bcr  19 


iNE  REPORT  -DETAIL 

RODLEM  MANAGER,  CODE        1130 
■rOGRAM  MANAGER,  CODE      1100 


PROBLEM/PROJECT 

N424/0SIS 


■onx'T'jtmr. 


WEEK  ENDING 

" ■■—  -7  December  1973 


MILESTONE 


IDENTIFICATION 


AN/UYK-4   Interface 

Dual   CRT  Switch 

IISOC  Interface 

OCR  Trade-Off  Analysis 

BR-700  Interface 

AN/UYK-4   Interface 

NSOC  Interface 

OCR  Trade-Off  Analysis 

Functional   Descrip  Rev 

Dual  CRT  Switch 


(West) 


Functional  Descrip  Rev  (East) 
OCC  526/GCC-48  Interf  Analysis 
Functional  Descrip  Rev  (East) 


S 

s 
s 
s 

D 
D 
D 
D 

D 
D 


S 
D 

D 


Z  Id  u 

?  ~° 
S2o 

a  -■>  u 

K 


MILESTONE  DATE 


1130 


Previous  FY-74  Milestones  Ccmnleted 


SCHEDULED 


9/4 
9/4 
9/17 
9/17 
11/2 
11/2 
11/2 
11/2 
11/16 
11/16 


9/4 
11/16 
11/23 


REVISED 


11/30 


11/16 

12/7 

12/7 


12/7 
12/14 


S    =    Start 
F    =     Finish 


P    =    Preliminary  E    a    Cxtern.21  Deliverable 

D   =    Deliverable  *    =    Completed  early 


CHECK  ON! 


ACTUAL 


9/4 
9/4 
*9/4 
*9/4 
11/30 
'11/6 
11/6 
11/15 


9/4 


MILESTONES  MISSED    (INCLUDE  REASONS,  EFFECT  ON  PROBLEM/PROJECT,  RfcMEDIAL  ACTION 
TAKEN,  AND  WHEN) 


TOTALS 


FY-74 
TOTALS 


29 


38 


1 1- 

i?  o 

ex" 
jj'i 


v 

A' 


12  5 


o.  210-  This  milestone  was  missed  due  to  delay  in  typing.  Estimated  completion 

date  is  14  December  1973.  Minor  impact  on  the  program  is  anticipated. 

Responsible  code  is  Cede  1130. 
o.  209A  -  This  document  was  rejected  by  project  QA  on  6  December.  Estimated 

completion  date  is  14  December  1973.  Minor  impact  on  the  program  is 

anticipated.  Responsible  code  is  Code  1130. 
o.  214  -  This  milestone  was  missed  due  to  underestimation  of  the  complexity  and 

time  required  for  completion.  Estimated  completion  date  is  14  December 

1973.  Minor  impact  on  the  program  is  anticipated.  Responsible  code  is 

Code  1130. 


Ch.irt  RCV  D 


10  l  ember  1 


,ONE  REPORT- DETAIL 

,  PROBLEM  MANAGER,  CODE        1130 
(  PROGRAM  MANAGER,  CODE      1100 


111 

112 
115 
116 
119 
120 
114 
124 
123 
il3 
109 

no 

17 
118 
111 
21 
535 
136 
130 
140 
126 
129 
Ml 
!34 
!33 
128 
132 
131 


MILESTONE 


IDENTIFICATION 


c/o 
c/o 
c/o 

c/o 
c/o 


BR  Prog  Prod  &  Unit  C/O 
BT  Prog  Prod  &  Unit  C/O 
TMP  Prog  Prod  h   Unit  C/O 
TUR  Prog  Prod  &  Unit 
PCM  Prog  Prod  &  Unit 
TFM  Prog  Prod  &  Unit 
TUR  Program  Specs 
0MP  Prog  Prod  &  Unit 
MM  Prog  Prod  &  Unit 
TMP  Program  Specs 
BR  Program  Specs     o 
BT  Program  Specs 
PCM  Program  Specs 
TFM  Program  Specs 
CMP  Program  Specs 
MM  Program  Specs 
ROTA  S/S  Integration 
LONDON  S/S  Integration 
BT  Program  Prod  L   Unit  C/0 
System  Intearation 
TMP  Prog  Prod  &  Unit  C/0 
BR  Prog  Prod  &  Unit  C/0 
PCM  Prog  Prod  I   Unit  C/0 
NORFOLK  S/S  Integration 
TUR  Proa  Prod  &  4Jr.it  C/0 
TFM  Proa  Prod  &  Unit  C/0 
0MP  Prog  Prod  &  Unit  C/0 
KM  Prog  Prod  &  Unit  C/0 


PROBLEM/PROJECT 

N424/0SIS 


V7EE.K  ENDING 

7  December  197? 


53g 

U    *Si   (J 


MILESTONE  DATE 


Previous  FY-74  Milestones  completed 


5330 


SCHEDULED 


10/1 
10/1 
10/8 
10/8 
10/15 
10/15 
10/19 
10/22 
10/22 
10/26 
10/26 
10/26 
11/2 
11/2 
11/2 
11/9 
12/15 
12/15 
12/15 
1/7 
1/11 

T/n 
l/n 

1/14 
1/25 
1/25 
1/25 
1/25 


REVISED 


S    =    Start 
F    =    Finish 


P    *     Preliminary 
D   =    Deliverable 


E    =     External  Deliverable 
*    =    Completed  early 


11/16 


1  MILESTONES  MISSED    (INCLUDE  REASONS,  EFFECT  ON  PRO  ELEM/F  R  OJ  ECT,  REMEDIAL  ACTION 
TAKEN,  AND  WHEN) 


ACTUAL 


10/1 
10/1 
10/8 
10/8 
10/15 
10/15 
10/19 
10/22 
10/22 
v-  10/25 
10/26 

*10/19 
11/2 
11/7 

*11/1 
11/13 


CHECK   O' 


Id 
Q 
1 


X 

X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 
X 


10 


MISS  CO        l-i 


£lL) 


TOTALS 


FY-74 
TOTALS 


15 
26 


X 
X 


r     I D 
5     I  " 


0 
0 
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I'AIUKL  ' 
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/    - 


•    V  .    <    *  f  ft        Ml         Ul        A     1     1    f  •     % 


Chart  REV  B 


l )  a"  I*  I 


!()['.       :    r   1973 


iinn-NULi    i  nil 


)NE  REPORT 'DETAIL 

>ROBLEM  MANAGER',  CODE         1130 
PROGRAM  MANAGER,  CODE       1100 


f-ROULEM/f'KOJECT 

N424/0SIS 


WEEK  ENDING 


7  December  197! 


MILESTONE 


01 
02 

03 
04 
05 
06 


V  A 
J3A 
)9A 
I0A 
I1A 
I2A 
I3A 
I4A 
I5A 
!6A 
I7A 
I8A 


IDENTIFICATION 


Install    DFC-B/A  Conv-MUX 
DFC-B/A  Conv-MUX  Reproqrarnming 
Install    DFC-B/A  Conv-MUX 
Ship  DFC-B/A  Conv-MUX 
Checkout  DFC-B/A  Conv-MUX 
Checkout  DFC-B/A  Conv-MUX 


2  "  M 

a.  a  " 

v)  —  U 

U  "-I  O 

c 


4300 


DFCU  Delive 
Data  to  Cod 
PM-16  Rev  is 
DAC0M  Bypas 
Data  to  Cod 
DFCU  Delive 
Data  to  Cod 
PM-16  Rev is 


ry 

e  6430  (DFCU) 

ion  (DFCU) 

s  Fab  n  &  Test 

e  6430  (DAC0M) 

ry 

e  6430  (DFCU) 

i: 


>-,  /r-cri\\ 


DAC0M  Bypass  Fab'n  &  Test 
Data  to  Code 
NEDN/NIDN  Ii 
NEDN/HIDN  Ii 


6430  (DACOM) 
installation 
installation 


MILESTONE  DATE 


SCHEDULED 


7/2 

7/20 

7/20 

7/20 

7/23 

8/21 


9/4 

9/4 

9/4 

9/4 

9/4 

10/1 

10/5 

10/5 

11/2 

11/2 

11/12 

12/14 


REVISED 


7/30 


11/2 
11/9 


): 


S    ■    Stsrt 
F    =    Finish 


P    *    Preliminary 
D    =     Deliverable 


Extcrnsl  Deliverable 
Completed  eany 


MILLSTONES  MISSED   (INCLUDE  fcEASONS,  EFFECT  ON  PF;0  LlLEM/PnOJ  ECT,  REMEDIAL  ACTIO,") 
TAKEN,  AND  WHEN) 

':.    Milestone  No.   105  date  revised  on  7/20/73. 


(\ 
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ACTUAL 


:mecx  onc        u 


7/2 

7/27 

7/27 
7/20 

7/30 

8/21 


u 

Q 
< 

5 


X 

X 

X 
X 

X 

X 


9/4 

X 

9/4 

X 

9/4 

X 

9/4 

X 

9/4 

X 

11/2 

X 

11/9 

X 

10/5 

X 

11/2 

X 

11/2 

X 

11/12 

X 

TOTALS 


TOTALS 


17 


,SL 


Chart  REV  A 


IUKL  ,y  |      i  \,  lUAH 

cU.,l.,(    v.! ,  A j  >.',-. . ,.    .  I     i<  . 

—  -         ■  ■— t—  r- 


r-.—  j-i-.ir-  ..-y*-.rurrcxca 


Igi  i\tsi-ofjMiii  i-  couniii  and  nam  ki.spicti  vt£  t;L/i  hkao(S) 


l£  REPOKI    -  Utl  AIL. 

lODl-EM  MANAGER,  CODE          H  30 
10GRAM  MANAGER,  CODE        H  00 

■    • 

N424/0SIS 

7  De 

;ember  1973 

MILESTONE  DATF 

chick  oni:      |  <- 

'.   CI  w 

?  ^  « 
«  -  O 
u  >•■>  <J 

u 

D 

< 

5 

r.  _-■ 

o   c 
(CD 

'CO 

MILESTONE 

SCHEDULED 

REVISED 

ACTUAL 

r  ~:  <■'■ 

5. 

IDENTIFICATION 

u  £  ^ 

V 

2480 

IB 
iiB 
'B 
!B 

i»B 
!!B 
i'B 
l!B 
!!B 
)B 

Install   Development  Facility 
Autodin  Plan 
Install   Eota   (Lab) 
Install   London   (Lab) 
Install   Development  Facility 
Install   Norfolk  (Lab) 
Autodin  Plan 
Install   Rota   (Lab) 
Install   London   (Lab) 
Install   Norfolk  (Lab) 

s 
s 
s 
s 

F 

s 

D 
F 
F 
F 

8/13 
9/4 
9/17 
9/24 
9/28 
10/1 
11/2 
11/30 
12/7 
12/14 

10/15 

2/1 

TBD 

8713 
9/4 
9/17 
9/24 
9/28 
10/15 
*11/1 

X 
X 
X 
X 
X 
X 
X 

X 

X 
X 

X 

'B 

>B 

:!B 

SB 

Interconnect  System 
Interconnect  System 
Prepare  for  Shipment 
Prepare  for  Shipment 

Previous  FY-74  Milestones  con 

S 

F 
S 
F 

pleted 

12/17 
1/4 
2/25 
4/5 

1 

0 

0 

S    =    Start                  P    =    Preliminary 
F    =     Finish               D   =    Deliverable 

E    =    External  Deliverable 
*    =    Completed  early 

TOTALS 

7 

0 

3 

l 

ILE 

STONES  MISSED    (INCLUDE   REASONS,  EFFECT  ON  PROP- 
TAKEN,  AND  WHEN) 

.EM/PRO 

JECT,  RCI.'.ED 

AL.  ACTION 

FY-74 
TOTALS 

8 

0 

3 

113B  -  This  milestone  was  missed  due  to  late  supply  of  PDP11  equipment  from 
NAVELEX.  Estimated  completion  date  is  to  be  determined  and  will  be 
reported  when  known.  Minor  impact  on  the  program  is  anticipated. 
Responsible  code  is  Code  1000. 
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Chart  REV  C 
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DAI  L 


lui  nc.si'ON 


10  Dcci    bor   ! 

t  INU   M   LC-1    Jinu/ILJ   (M   V.  {,/  .) 


)NE 

REPORT -DETAIL 

PROBLEM/PKOJLX1 

IVELK  ENDING 

TiOBLEM  MANAGER,  CODE           1130 

N424/0SIS 

7  December  1 973 

" 

PROGRAM  MANAGER,  CODE          1100 

5  W  Id 

u  m  u 

MILESTONE  DATE 

ClirCK  onz 

- 

111 
o 
< 

r.'ir.MiO 

I  ■  •      c 

MILESTONE       / 

Twrnui  r  n 

REVISE  D 

ACTUAL 

~pr 

?     !  i  ',  '- 

No. 

IDENTIFICATION 

_.  v,  n  l_L>V/l-l—  L' 

^ 

il=L 

;- 

01 

A-B-A  Hdwre  Tech  Man   (Type  II) 

S 

C430 

10/1 

10/1 

X 

02 

A-B-A  Software  Proj  Manual 

S 

10/1 

10/1 

X 

03 

Elint  L.   D.   Hdware  Tech  Man 

S 

10/1 

10/1 

X 

06 

DFCS  Hdware  System  Tech  Manual 

S 

1*0/23 

10/23 

X 

07 

DFCS  Software  Proj  Man   (TTY   Int) 

S 

10/23 

10/23 

X 

08 

DFCS  Software  Project  Man   (LPInt) 

S 

10/23 

10/23 

X 

09 

..DFCS  Software  Project  Man   (TPInt) 

S 

10/23 

10/23 

X 

10 

DFCS  Software  Project  Man   (TRInt) 

S 

10/23 

10/23 

X 

04 

Elint  L.   D.   Hdv/are  Tech  Man 

D 

11/2 

11/2 

X 

05 

NELC  Review  (No.   104) 

S 

11/5 

41/5 

X 

11 

NELC  Review  (No.   104) 

F 

11/9 

11/9 

X 

12 

Elint  L.D.   Hdv/re  Tech  Man   (Update 

)S 

11/9 

11/9 

X 

14 

Elint  L.D.   Hdwre  Tech  Man(Update) 

F 

.11/26 

11/26 

X 

13 

NELC  Review  (No.   114) 

S 

11/26 

11/26 

X 

15 

NELC  Review  (No.   114) 

F 

11/30 

11/30 

X 

16 

A-B-A  Hdwre  Tech  Man   (Type  II) 

F 

11/30 

12/7 

12/4 

X 

X 

17 

A-B-A  Software  Proj  Manual 

F 

11/30 

12/14 

X 

18 

NELC  Review  (No.   116) 

S 

12/3 

12/4 

X 

19 

NELC  Review  (No.    117) 

S 

12/10 

20 

NELC  Review  (No.    116) 

F 

12/17 

*12/7 

X 

21 

A-B-A  Hdwre  Tech  Manual    (Uodate) 
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VIP  Program  Specs 

S 

5200 

8/13 

8/13 

X 

102 

ONH  Program  Specs 
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8/13 

X 

104 
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BTCH  Program  Specs 
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OTCH  Prog  Prod  &  Unit  C/0 
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TCH  Program  Specs 
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BTCH  Program  Specs 
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FY-74 
TOTALS 


22 


26 


0 
0 


113  &  114  dates  revised  10/15 
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I  TO:    lll.'.l'ur'^im.i:  COUI.  (S)  ANO  THtlfl  HCSPCCTIVI    DEIM   HLAO(S) 


Chart  REV  C 


Ida  1 1. 


10  December  ) 


1  I  HO-NI  i  COT-JOOO/ltJ  (ii   w-.  (/•/: 


CONFIGURATION  CONTROL 

The  following  three  pages  are  examples  of  forms  used 
by  the  WWMCCS  Project  Office  in  tracking  and  controlling 
engineering  changes  within  the  project.  Requiring  a  for- 
mal process  such  as  this  when  engineering  changes  are 
performed  maintains  the  necessary  checks  and  balances  on 
changes  to  the  design.  It  allows  the  project  manager  to 
track  the  actual  make-up  of  the  equipment  being  developed, 
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ENGINEERING  CHANGE  ORDER 


ECO  Mo. 

imr  es  I  Cn  f.'c) 


Date 


1.   ECOTITLF. 

fSame  OS  LCR) 


2.   IMPLEMENTATION  SCHEDULE 
Documentation 

Program  Development 

Hardware  Changes 


Start  Date 


Completion  Date 


■-                     1 

System  Version 
(IOC.  etc.) 

Phase  (1  or  II) 

Release  Date 

(Att'ch  copy  of  revised  ii/£>Air  chert  refkrtint  this  ehjrjrc) 


3.  SYSTEM  DESIGN  SPECIFICATIONS 

This  pcrj^'iph  *.//.'  cwi I : in  the  system  desitn  specifications  for  each  function  requiring  modification.    This  drslpi  will  t-c  prepared  consistent 
with  the  G'S!S  perfiwnjR:c  jr~i  design  s-.cctfit.jt.ons  and  tie\nupmeni  for  tin  cpprupuste  icrsion.   functions  *.:/:  be  specified  separately  e.j 
h  the  System  Design  Speci/icmisnt  to  case  the  Juture  update  of  tint  document. 


4.   HARDWARE  CHANGES 

Jlerdntase  chJnjej  required  mil  be  noted  wilh  fnrrtinr.nl  comments  on  eutaliction  date  or  ether  necerary  information. 


5.  DOCUMENTATION  CHANGES 

(l-iil  //«r  documents  tr^jt  w;U  rro^ee  ypuatCJ 


6.  This  change  will  be  incorporated  in  the  next  revision  of  IWA(s): 


•  Implementation  jutiioriicd  ;nd  diiccted: 


J.  C.  Caldwell.  Code  I  )  .■'.■ 


im~iiELC~4i:t.)/ii  [i..n) 
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ENGINEERING  CHANGE  REQUEST 


ECR  No. 


Date 


ft   Originator  (NELC/NIPPSSA/User) 


3.   Document(s)  Affected/Title  of  Changs: 


4.   Description  of  Changs: 


5.   Reason  for  Change: 


6.   Estimated  Impact: 


Phase  i       YES       NO 


Phase  II       YES       NO 


Jgxptein  "YES"  response.    Include  revised  schedule  dares,  etc.) 


7.   Estimated  Effects  on  Parforrr.zncc/Design  Spccisicsiions: 

8.   Rough  Order  of  Magnitude  Schedule  and  Cost  Impact  Statement: 

• 

Submitted: 

(Task  Leader  Signa  lure  J 

CONFIGURATION  CHANGE  CONTROL  BOARD  ACTION 

Approved: 

Disapproved: 

(Dole) 

(Date) 

Analysis  Due: 

Prom  (Cede): 

' 

(lieu) 

• 

Clu.ir 

man: 

I 

IS  irnc  m.  <e  i 
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FIELD  ENGINEERING  CHANGE  REPORT 


FECR  No. 


Date: 


1.  Originator: 


2.  Description  of  Change: 


3.  Reason  for  Chance: 


4.  Estimated  Effects  on  Performance: 


Submitted: 


(On-Sitn  Team  i.r.icer) 


Forwarded: 


(Task  Leader) 


Noted:  _ 


(Project  Manager) 
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PROGRAM  EVALUATION  AND  REVIEW  TECHNIQUE  (PERT) 

PERT  was  developed  for  the  Navy's  Polaris  mlssle  project 
In  1958  and  is  credited  with  playing  an  important  role  in 
bringing  missies  into  operation  two  years  earlier  than  an- 
ticipated.  PERT  is  basically  a  Critical  Path  Method  of 
planning  and  controlling  using  a  probability  distribution 
to  estimate  most  likely  path  lengths. 

PERT  is  an  excellent  tool  by  which  a  project  manager 
can: 

•  estimate  the  time  at  which  each  milestone  in  the 
project  can  be  expected, 

•  predict  slippages  and  estimate  the  effect  of  slip- 
pages, 

•  select  the  "critical  path"  of  those  activities  which 
cannot  be  delayed  without  jeopardizing  the  entire 
project , 

•  force  the  project  manager  to  draw  a  network  and 
thereby  think  about  his  planning  task, 

•  logically  show  how  events  relate. 

PERT  has  faults,  not  the  least  of  which  is  its  complexity, 

but  some  variation  of  the  critical  path  network  can  be  used 

by  every  project  manager  as  a  tool  to  assist  in  planning  for 
and  controlling  his  project. 


Ill 
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